Smart Talk Episode 7:Menavigasi Kardinalitas, Kontrol, dan Biaya dalam Observabilitas

Kami telah membahas observabilitas dan ruang pelengkap AIOps beberapa kali dalam seri ini, tetapi kali ini, kami mendalami topik tersebut secara lebih pragmatis untuk memahami mentalitas pembeli. Apa yang harus dicari oleh CIO suatu organisasi ketika mereka mencari solusi observasi? Bergabunglah bersama kami dalam episode ini saat Dinesh Chandrasekhar, Kepala Analis dan Pendiri Stratola, berbicara dengan Krishna Yadappanavar, CEO Kloudfuse. Krishna menjelaskan observabilitas melalui kacamata tiga faktor – Kardinalitas, Kontrol, dan Biaya.
3 C ini adalah kunci untuk memahami dan mengelola data observabilitas yang terus meningkat. Faktor-faktor ini tidak hanya penting untuk mengelola data tetapi juga untuk memanfaatkan data dan meta data untuk analisis tambahan.
Perkembangan baru di bidang observabilitas adalah observabilitas model, khususnya LLM yang mendorong AI generatif. Prinsip 3 C juga berlaku untuk kasus penggunaan yang sedang berkembang ini.

Beberapa topik yang dibahas dalam Smart Talk episode kali ini adalah:

• Potensi data observabilitas
• Proliferasi alat
• Mengatasi data observabilitas yang tersembunyi
• Mempertimbangkan metadata
• Wawasan tentang biaya

Tamu
Krishna Yadappanavar, CEO, Kloudfuse
Krishna Yadappanavar adalah Salah Satu Pendiri dan CEO Kloudfuse, sebuah platform observasi terpadu. Dia sebelumnya ikut mendirikan SpringPath, mendapatkan pendanaan $94 juta dan memimpin perusahaan tersebut mengakuisisi $320 juta oleh Cisco. Dengan lebih dari 20 paten, Krishna telah memberikan dampak signifikan terhadap teknologi data, virtualisasi, dan penyimpanan di Veritas, Commvault, EMC, VMware, dan Cisco. Dia ikut menulis VMFS VMware dan merancang komponen penting dari tumpukan virtualisasi penyimpanan untuk ESX Server. Selain itu, Krishna memberi nasihat dan berinvestasi pada startup baru di bidang Data, Virtualisasi, Cloud, Keamanan, dan AI/ML, sehingga berkontribusi pada visi, strategi produk, teknik, dan upaya memasuki pasar.

Pembawa acara:  Dinesh Chandrasekhar adalah penginjil teknologi, pemimpin pemikiran, dan analis industri TI berpengalaman. Dengan pengalaman hampir 30 tahun, Dinesh telah mengerjakan perangkat lunak perusahaan B2B serta produk SaaS yang memberikan dan memasarkan solusi canggih untuk pelanggan dengan arsitektur kompleks. Dia juga telah mendefinisikan dan melaksanakan strategi GTM yang sangat sukses dengan meluncurkan beberapa produk dengan pertumbuhan tinggi ke pasar di berbagai perusahaan seperti LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM dll. Dia adalah pembicara yang produktif, blogger, dan pembuat kode akhir pekan. Dinesh meraih gelar MBA dari Santa Clara University dan gelar Master di bidang Aplikasi Komputer dari University of Madras. Saat ini, Dinesh menjalankan perusahaannya sendiri, Stratola, sebuah perusahaan konsultasi strategi bisnis dan layanan pemasaran lengkap yang berfokus pada pelanggan.

Sumber Daya
Smart Talk Episode 6:AIOps dan Masa Depan Pemantauan TI
Smart Talk Episode 5:Disagregasi Tumpukan Observabilitas
Smart Talk Episode 4:Data Real-Time dan Database Vektor
Smart Talk Episode 3:Saluran Data Modern dan LLM
Smart Talk Episode 2:Bangkitnya Aplikasi GenAI dengan Data-in-Motion
Smart Talk Episode 1:Lanskap Ekosistem Data-in-Motion
Lihat peta ekosistem data-in-motion di sini
Pelajari lebih lanjut tentang data-in-motion di RTInsights di sini

Transkrip
Dinesh Chandrasekhar

Halo dan selamat datang di episode Smart Talk ini, seri kepemimpinan Data in Motion. Dan di episode kali ini kita kedatangan tamu istimewa, Krishna Yadappanavar. Dia adalah CEO Cloud Fuse. Dia tidak asing dengan ekosistem startup. Dia adalah seorang pengusaha serial. Dia telah membangun beberapa perusahaan sebelumnya, jadi kami dengan hangat menyambut Krishna untuk berdiskusi tentang observabilitas, yang sekali lagi merupakan tema favorit dalam seri ini. 

Krishna Yadappanavar

Terima kasih.

Dinesh Chandrasekhar

Jadi Krishna, sebagai cara untuk memperkenalkan diri Anda, mengapa Anda tidak memberi tahu kami tentang Kloudfuse dan dorongan Anda untuk memulai perusahaan?

Krishna Yadappanavar (01:01):

Oke, tentu saja. Terima kasih, Dinesh. Terima kasih atas perkenalan yang hangat. Hai teman-teman, nama saya Krishna. Ya, saya sudah tinggal di Valley selama hampir dua dekade lebih dan telah bekerja dengan banyak perusahaan rintisan dan perusahaan besar. Namanya yang terkenal seperti VMware ketika masih awal startup. Saya bergabung dan kemudian melihatnya berkembang dari hampir satu juta ERR menjadi 64 miliar perusahaan dan saya telah dikaitkan dengan berbagai teknologi terkait data, baik itu sistem file penulisan, sistem terdistribusi, database atau OLAP atau OLTP. Oke, jadi sepanjang perjalanan ini yang saya perhatikan adalah data adalah rahasia dari semua wawasan, baik itu di sisi analisis produk atau menyediakan solusi seperti virtualisasi atau memberikan solusi seperti pencadangan atau pemulihan bencana. Setelah menyelesaikan startup saya, Springpath, yang berada dalam tahap hiperkonvergensi, mencoba menyatukan konvergensi penyimpanan, jaringan, keamanan dalam sebuah kotak yang saya jual ke Cisco.

Dan setelah menghabiskan beberapa waktu di Cisco, saya memikirkan tren besar berikutnya yang akan datang? Hal ini terjadi pada awal tahun 2020. Saya menemukan beberapa tren, seperti beberapa tren yang terkait dengan bagaimana data terkait dengan pengembang DevOps atau SecOps tumbuh secara eksponensial. Bagaimana tren baru dalam pembelajaran mesin model AI dan LLM saat model LLM masih dalam tahap awal akan mengganggu pasar? Dan ketika otak manusia mulai berpikir dan bereaksi terhadap kejadian tertentu, Anda ingin mesin bertindak dengan cara yang sama. Ini adalah beberapa masalah yang kami temui dan di persimpangan ketiganya, saya menemukan bahwa, memecahkan masalah tidak hanya kemampuan observasi, namun kemampuan observasi ditambah analitik dan otomatisasi, selain data, yang difokuskan pada pengembang dan DevOps sangatlah penting. Hal itulah yang menjadi awal dimulainya Kloudfuse–yang satu mengarah ke yang lain dan kemudian kami menjadi tim yang beranggotakan sekitar 40 orang lebih sekarang.

Dinesh Chandrasekhar (03:16):

Selamat dan ini adalah awal yang baik. Jadi semoga Anda beruntung dalam perjalanan itu. Berbicara tentang observabilitas, ini bukanlah sesuatu yang terjadi kemarin. Saya juga bekerja di bidang itu selama cukup lama dan konsep observabilitas telah berkembang selama bertahun-tahun. Jadi awalnya 10, 12 tahun yang lalu orang-orang heboh membicarakan pemantauan infrastruktur, pemantauan jaringan, dan sebagainya, lalu perlahan-lahan satu hal mengarah ke hal lain dan kemudian ada pemantauan cloud dan kemampuan pemantauan kontainer yang ditambahkan. Dan saat ini kita memiliki gagasan tentang observabilitas yang cukup populer. Sebagian besar perusahaan yang dulunya menggembar-gemborkan pemantauan kini menjadi perusahaan yang dapat diobservasi. Dan saya tahu Anda memulai dari awal di bidang observasi dan ingin menciptakan perbedaan. Bagaimana Anda menggambarkan evolusi ini? Apa yang sebelumnya dibandingkan dengan apa yang kita miliki saat ini? Bagaimana Anda melihat evolusi ini?

Krishna Yadappanavar (04:09):

Ya, pertanyaan bagus. makan malam. Saya telah melihat ini, maksud saya sebagai pengembang sendiri yang menulis aplikasi monolitik yang berjalan di mesin fisik. Kemudian saya melihat munculnya virtualisasi, apakah itu seperti VMware atau Hyper-V atau teknologi virtualisasi sumber terbuka dan kontainerisasi masuk. Jadi, jika Anda melihat masalah inti dalam hal observasi data, seiring dengan berkembangnya evaluasi ini, kita telah melihat atribut yang terkait dengan data terus meningkat, dan ketika Anda mengambil produk Cartesian dari atribut tersebut, maka atribut tersebut menjadi sangat besar dalam urutan jutaan hingga miliaran. Apa yang mereka sebut sebagai kardinalitas yang terkait dengan kardinalitas tersebut adalah volume data. Ketika volume data meningkat, orang ingin mengubah data A menjadi data B untuk analisis yang lebih baik. Mereka ingin mengotomatiskan alur kerja tertentu selain data.

Mereka ingin memilah-milah data sehingga dapat memberi Anda wawasan yang lebih baik. Jadi singkatnya, ketika volume data meningkat dengan cara tradisional, hei, saya memantau apa yang disebut sebagai hal yang diketahui hilang, yaitu pemantauan tradisional. Kemudian Anda melihat pada hal-hal yang tidak diketahui, yang merupakan awal dari kemampuan observasi dan ada hal-hal yang tidak diketahui sepenuhnya yang mana Anda tidak tahu apa-apa dan Anda dihadapkan pada data bernilai multi-terabyte hingga petabyte dan Anda harus membedah data tersebut dan mendapatkan kata-kata yang lebih baik di mana sebenarnya masalahnya, bagaimana korelasinya dengan kejadian, apa analisis akar permasalahannya, apa analisis dampaknya. Jadi selama pengembang menulis kode, kompleksitas ini dan semakin banyak layanan akan datang. Kompleksitas ini akan semakin tinggi dan oleh karena itu hal ini akan terus berkembang dan menjadi tempat munculnya tantangan-tantangan baru.

Dinesh Chandrasekhar (06:14):

Fantastis. Jadi observabilitas jelas merupakan masalah yang sulit dipecahkan. Saya ingin sekali menyelidiki mengapa demikian? Namun menurut saya Anda juga sudah sedikit membahasnya sekarang, namun hal ini juga disebabkan oleh fakta bahwa kita memiliki pasar yang ramai dengan selusin vendor di luar sana yang mengatakan, kita menyelesaikan bagian dari kemampuan observasi ini dan kemampuan observasi semacam itu dan sebagainya, namun masih ada pencarian untuk solusi yang ideal. Jadi setiap CIO yang saya ajak bicara selalu mencari solusi ajaib yang bisa memecahkan masalah mereka. Mengapa demikian? Apakah ada sudut pandang berbeda yang harus Anda gunakan untuk melihatnya guna memahami mengapa ada dorongan berbeda untuk mendapatkan solusi ideal tersebut?

Krishna Yadappanavar (07:04):

Jadi seperti yang saya singgung sebelumnya izinkan saya mundur sedikit, bukan? Apa yang dicari pelanggan ketika mereka memikirkan solusi observasi yang ideal? Mari kita mulai dari masalahnya. Saya mengklasifikasikan masalah ini ke dalam tiga C – Kardinalitas, Kontrol, dan Biaya. Biarkan saya masuk ke tingkat detail berikutnya. Apa maksud dari ketiga C tersebut? Kardinalitas, ini semua tentang bagaimana kami memiliki data tertentu, apakah itu titik metrik yang rumit atau logline atau peristiwa atau jejak atau rentang yang berasal dari penelusuran distributor Anda atau profil profil berkelanjutan, data tersebut dilampirkan dengan tambahan, karena tidak adanya kata, label, atau tag yang lebih baik. Ketika Anda mengambil produk Cartesian dari nilai potensial yang dapat diambil oleh label tersebut, maka produk tersebut akan tumbuh sangat, sangat tinggi. Jadi sekarang setiap titik data harus dikaitkan dengan tagnya.

Jadi sebut saja tag sebagai metadata. Lalu ada datanya. Skema yang berbeda mempunyai permasalahan yang berbeda pula. Beberapa di antaranya memiliki banyak metadata. Saat Anda membuka situs matriks, saat Anda membuka log dan rentang seperti penelusuran terdistribusi, keduanya seperti data yang berat, namun sebenarnya, ini adalah peningkatan yang luar biasa dalam volume data observabilitas karena kardinalitasnya. Saat ini saya telah melihat tren sebaliknya. Maksud saya, dulu orang-orang berpikir, Hei, izinkan saya mengirim data saya ke portal SaaS dan kemudian vendor SaaS akan mengelola semua data itu. Namun ketika saya berbicara dengan CTO atau CIO atau kepala teknik atau pengembang atau arsitek dan bahkan CFO, mereka berpikir, biarkan saya mengontrol data saya. Apa maksudnya? Ada tren sebaliknya yang terjadi ketika saya memiliki begitu banyak data karena berbagai alasan, apakah itu peningkatan biaya risiko, aspek keamanannya, atau volume data itu sendiri.

Mereka tidak ingin mengirim data tersebut ke luar VPC mereka dan ada sudut pandang lain dalam hal ini. Mereka ingin menghadirkan semua kemungkinan antarmuka yang dapat mereka pikirkan apakah itu untuk jenis antarmuka observatorium tradisional seperti membuat dasbor, peringatan, SLO, atau fungsi analitik apa pun yang dapat ditulis dalam SQL tradisional atau GraphQL atau mungkin ada pekerjaan tingkat lanjut seperti Spark untuk menjalankan beberapa analitik di atas data observabilitas karena observabilitas telah menjadi pilar fundamental. Itu berarti mereka harus memiliki datanya. Data tidak boleh meninggalkan VPC. Ketika saya menyebutkan data, data yang diserap, data yang ditanyakan, dan data yang dianalisis, dan yang terakhir adalah biayanya. Jika Anda pergi ke vendor mana pun di luar sana, apakah itu vendor komersial SaaS tradisional atau komponen sumber terbuka, dan ada banyak solusi sumber terbuka di luar sana. Biaya infrastruktur, biaya vendor berbanding lurus dengan volume data, berbanding lurus dengan jumlah query, dan berbanding lurus dengan jumlah pengguna. Ketiga hal tersebut adalah masalah yang dicari oleh organisasi tradisional yang mencari solusi ideal, solusi observabilitas ideal

Dinesh Chandrasekhar (10:24):

Kardinalitas, kontrol, dan biaya. Saya rasa saya menyukainya. Tiga C adalah cara yang bagus untuk melihat ruang observasi dan bagaimana Anda menyimpulkan apa yang penting bagi pengguna sebenarnya dan seterusnya. Berbicara tentang biaya, sejak kita membahasnya, saya ingin menanyakan pertanyaan ini juga. Dari pengalaman pribadi saya, ketika saya berbicara dengan pelanggan yang mencari solusi observasi, yang sering mereka keluhkan adalah, Hei, saya memiliki setidaknya delapan hingga 10 alat berbeda di setiap departemen yang saya miliki. Saya sedang mencari sekitar 30 hingga 40 alat di seluruh organisasi saat ini. Saya sudah mengeluarkan banyak biaya untuk membayar lisensi ini dari tahun ke tahun. “Mengapa saya menginginkan satu lagi solusi observasi,” adalah penolakan yang biasa saya terima, bukan? Jadi saya akan mengajukan pertanyaan yang sama kepada Anda sekarang setelah Anda menyentuh aspek biaya. Bagaimana Anda mendekati pertanyaan tersebut dengan CIO dan meyakinkan mereka atau memberi tahu mereka mengapa hal ini lebih baik daripada memiliki 30 atau 40 alat berbeda?

Krishna Yadappanavar (11:23):

Oke, pertanyaan bagus. Jadi untuk menjawab pertanyaan itu, mari kita mulai dengan masalah mengapa ada proliferasi alat. Jadi jika Anda melihat keseluruhan ekosistem, secara tradisional beberapa vendor, jika saya ambil vendor komersial, mereka cukup bagus di aliran tertentu. Jika Anda membuka log, Anda dapat memikirkan Splunk. Jika Anda memikirkan metrik, Anda memikirkan Datadog. Lalu di dalam Google dan semua FANG di dunia. Seluruh pergerakan open source ini dimulai, terutama dengan munculnya Kubernetes, kemudian muncullah Prometheus, OpenTelemetry, dan yang lainnya.

Dan ada seluruh pergeseran yang sedang terjadi menuju solusi berbasis sumber terbuka. Apa maksudnya? Itu berarti para pengembang, arsitek, orang-orang DevOps ingin menyerap data observasi mereka dalam format terbuka. Artinya, meskipun saya memilih instrumentasi apa pun untuk menginstrumentasikan kode saya atau menempatkan agen mana pun untuk mengumpulkan data saya, itu harusnya seratus persen kompatibel dengan sumber terbuka. Itulah sebabnya ketika vendor komersial juga mulai menempatkan agen mereka di sumber terbuka, maka di sisi kueri, mereka menginginkan keseluruhan visualisasi, dasbor, peringatan–semua kemampuan ini didorong oleh bahasa kueri sumber terbuka. Itu sebabnya munculnya PromQL, LockQL, TraceQL, OpenTelemetry, mereka kini mencoba bahasa kueri sumber terbuka lainnya.

 Jadi sekarang Anda berada di dunia di mana Anda memiliki banyak pilihan. Pelanggan sudah memilih aliran tertentu, vendor tertentu.

Lalu ada pergerakan open source dan tim berbeda menggunakan infrastruktur berbeda. Ada yang berbasis Kubernetes, ada yang berbasis tanpa server, ada yang berbasis ECS, Fargate, dan lainnya. Sehingga menambah dimensi lain dan untuk mencapai kecepatan dan ketangkasan penyampaian produk secara keseluruhan, CI/CD telah berevolusi di persimpangan ini untuk menyelesaikan masalah dengan sangat cepat. Mereka mencoba mencari solusi yang tepat dan akhirnya memilih solusi yang sangat tepat. Saat itulah kita sebagai solusi observabilitas yang ideal, jika saya memulai tumpukan observabilitas untuk perusahaan saya, saya akan mundur dan berpikir, hei, jika saya ingin mengurangi MTTR dan MTTD, saya perlu mengumpulkan semua aliran akhir data observasi. Apakah saya pergi ke n vendor yang berbeda dan pilih n aliran yang berbeda, atau apakah saya pergi ke danau data observasi di mana saya dapat menggabungkan semua aliran sehingga korelasi, fungsi lanjutan seperti deteksi outlier, anomali, sebab akibat menjadi relatif lebih mudah? Itu akan menjadi solusi ideal di mana Anda dapat menggabungkan semuanya dalam data lake tempat Anda dapat menyimpan data di dalam lokasi Anda.

Dinesh Chandrasekhar (14:18):

Fantastis. Dan saya juga ingin menambahkan bahwa biaya untuk proliferasi alat, saya setuju sebagian besar karena pengembang ingin membangun produk mereka sendiri dan mereka juga telah menambahkan banyak alat sumber terbuka ke dalamnya, tetapi juga pembelian di tingkat departemen. Jadi departemen TI merasa saya bisa menyelesaikan masalah ini karena izinkan saya mendapatkan solusi bandaid, izinkan saya membeli alat ini dan menggunakannya. Dan kemudian seiring berjalannya waktu mereka menyadari bahwa mereka telah menambahkan satu alat lagi ke dalam gudang senjata mereka dan tanpa menyadari bahwa mereka tidak mencari pepohonan di hutan. Jadi percakapan CIO selalu menarik dan tentang bagaimana Anda dapat memadatkan atau mengurangi jumlah alat yang Anda miliki di seluruh perusahaan dan memiliki satu platform observasi yang dapat melihat ke seluruh departemen, melihat ke seluruh aplikasi, wadah infrastruktur, dan yang lainnya. 

Krishna Yadappanavar (15:08):

Tentu saja. Jadi saya ingin menambahkan bahwa sekarang persona yang berbeda di perusahaan juga melihat data yang sama. Seperti pengembang DevOps, semua arsitek melihat data observasi sehubungan dengan infrastruktur, aplikasi containerisasi, dan lainnya. Menggunakan log yang sama. Orang-orang SecOps mencoba membedah data untuk mencari keamanan dan ancaman. Melihat data serupa yang berasal dari log atau jejak. Bahkan orang-orang DataOps pun bertanya-tanya, Hei, seberapa bagus operasi data saya? Dan sekarang dengan munculnya LLM, bahkan orang-orang Operasi LLM pun mencari data serupa untuk melakukan analisis mereka. Jadi ada konsolidasi lain yang perlu dilakukan. Itu adalah satu hal yang saya cari dalam solusi observasi yang ideal. Bagaimana cara memasukkan semua persona yang berbeda dalam suatu organisasi sehingga mereka dapat memanfaatkan data dari data lake yang sama.

Dinesh Chandrasekhar (16:05):

Benar-benar satu-satunya hal yang telah kita perjuangkan selama ini. Jadi itu hal yang bagus. Jadi saya ingin menyinggung satu hal lagi yang Anda sebutkan secara singkat saat Anda menjelaskan jawaban sebelumnya, yaitu tentang pengurangan MTTR, bukan? Jadi, sebagai inti utama dari kemampuan observasi, ini bukan hanya tentang pemecahan masalah tetapi juga tentang pengurangan MTTR, mengurangi gangguan peringatan dan juga metrik semacam itu. Jadi hal ini jelas menyelamatkan SRE dan IT Ops dari keharusan mencari tahu di mana masalahnya dan semua itu sebagai persyaratan mendasar utama untuk menyelesaikan masalah ini. Anda memerlukan akses ke peristiwa real-time yang sedang berlangsung. Jika ada log yang dimasukkan dalam aplikasi tertentu atau server tertentu tentang aktivitas jahat atau semacamnya, Anda memerlukan akses ke peristiwa tersebut segera saat itu juga sehingga Anda dapat memahami di mana anomali tersebut berada, apa yang terjadi di seluruh infrastruktur Anda, mengapa lonjakan khusus ini pada thread memori tertentu atau apa pun.

Jadi, Anda perlu memikirkannya dan agar hal itu terjadi, Anda juga memerlukan kemampuan untuk menyerap semua ini secara real-time. Kedekatan data, yang merupakan istilah favorit saya selama setahun terakhir, dan kesegaran data adalah hal yang sangat penting di sini. Inilah yang kita bicarakan, seberapa segar datanya, seberapa cepat Anda dapat menyelesaikan masalah tertentu atau bahkan mungkin mencegah sesuatu yang akan terjadi dalam konteks kemampuan observasi khusus ini, terutama ketika Anda berbicara tentang ratusan dan ribuan server yang Anda pantau dan sebagainya, atau di mana Anda bisa mengatakan, di sinilah masalahnya dalam hal membuat data menjadi sesegar mungkin atau tidak. Apakah hal ini sangat bergantung pada mekanisme konsumsi? Karena Anda berbicara tentang TEL dan jenis teknik instrumentasi lainnya dan sebagainya. Jadi, bagaimana lagi Anda memikirkannya atau melihatnya dari perspektif seberapa cepat saya bisa mendapatkan akses ke data real-time?

Krishna Yadappanavar (18:03):

Oke, aspek hebat lainnya dari tim observasi, Anda benar sekali, Danesh. Jadi dimensi kunci di mana data observatif dikonsumsi adalah seberapa cepat saya dapat memperoleh data tersebut, kapan data tersebut telah meninggalkan sumber datanya, apakah itu aplikasi Anda atau komponen infrastruktur Anda atau platform Anda seperti komponen sumber terbuka dan hal-hal seperti itu. Oleh karena itu, jika Anda melihat bagaimana industri ini berkembang dalam lima hingga 10 tahun terakhir ini, layanan streaming realtime dan database realtime telah hadir. Jika Anda melihat solusi observasi tradisional, maksud saya mereka tidak dapat memanfaatkan fungsi tersebut karena teknologinya relatif lebih tua. Jadi dengan munculnya streaming waktu nyata dan database waktu nyata, Anda dapat mengakses data secepat mungkin. Jadi itu adalah ukuran dari apa yang disebut sebagai kesegaran data sejak data tersebut meninggalkan aplikasi hingga siap untuk di-query, itu yang terpenting.

Lalu ada aspek seperti, hei, saya punya semua datanya. Bagaimana cara mengelompokkan data tersebut? Bagaimana cara menemukan pola relevan yang saya perlukan untuk mencapai akar permasalahan adalah rangkaian masalah berikutnya. Artinya saya harus bisa mengubah data satu ke data lainnya. Hei, saya mendapatkan serangkaian log. Bisakah saya melihat metrik dari log dengan cepat? Saya mendapatkan serangkaian rentang. Dapatkah saya melihat beberapa atribut dalam rentang tersebut atau jejak untuk menganalisis data tersebut? Karena atribut ini biasanya berkorelasi dan itulah cara proses debug terjadi. Jadi itulah dimensi berikutnya. Dan dimensi ketiga adalah analitik tingkat lanjut. Selain data tersebut, dapatkah saya memberikan beberapa statistik menarik atau model bahasa besar untuk menganalisis data guna menemukan apa yang disebut outlier di sistem saya?

Bisakah saya menemukan anomali di sistem saya? Oke, bolehkah saya melihat aspek musiman pada data saya? Bisakah saya memperkirakan data saya berdasarkan apa yang saya lihat di masa lalu? Aspek musiman dari data? Jadi semua inilah yang saya sebut sebagai paket analisis tingkat lanjut. Jadi ketika Anda memikirkan solusi keseluruhan setelah data baru diselesaikan, Anda perlu memikirkan data sebagai satu unit batu bata dan kemudian bagaimana setiap batu bata dapat disesuaikan dan kemudian mengatur fungsi analitik. Dan hal wajar yang perlu kita lakukan adalah, hei, saya sudah menganalisisnya sekali, bisakah saya mengotomatiskannya? Itu menjadi perpanjangan alami dari semuanya. Oleh karena itu, seiring dengan masalah tiga C, kami melihat pelanggan bertanya bagaimana saya dapat mengamati, menganalisis, dan mengotomatiskan data pengamatan saya.

Dinesh Chandrasekhar (20:57):

Sangat keren. Sangat keren. Dan sebagai bagian dari tanggapan Anda, Anda juga menyebutkan kata ajaib LLM, model bahasa besar. Maksud saya, saat ini Anda tidak dapat melakukan percakapan tanpa membicarakan tentang GenAI LLM. Jadi saya senang Anda menyebutkannya karena saya pasti bisa menanyakan hal ini, yaitu observabilitas LLM. Sepertinya ini adalah ruang yang muncul secara tiba-tiba mengingat semakin banyaknya LLM di mana-mana dan orang-orang kesulitan memahami kinerja mereka dan sebagainya. Jadi beritahu kami tentang hal itu. Sepertinya Kloufuse juga sedang membangun sesuatu di bagian depan itu, bukan? Jadi, ceritakan lebih lanjut kepada kami.

Krishna Yadappanavar (21:32):

Maksudku, ya. Maksud saya pada dasarnya secara keseluruhan, model LLM diterapkan dalam berbagai kasus penggunaan, bukan? Adapun kurangnya kata yang lebih baik. Dinamika perubahan data, apalagi dalam dunia observability, datanya sangat dinamis. Membangun model LLM yang tepat untuk melakukan operasi tertentu selalu sulit. Jadi kita telah melihat masalahnya dalam dua cara. Bagaimana saya bisa memanfaatkan model LLM tertentu di atas data observabilitas yang ada, yang dikonsumsi oleh semua persona berbeda yang saya bicarakan, apakah itu DevOps atau SecOps atau DataOps atau LLMOps. Itulah salah satu aspeknya. Dan ada aspek lainnya, hei, saya sedang mengembangkan aplikasi di mana LLM merupakan komponen yang sangat, sangat penting. Bagaimana cara melihat observabilitas lengkap dari aplikasi yang menghasilkan data, yang dimasukkan ke dalam LLM, dan kemudian ada banyak konsumen yang menggunakan data tersebut dari model LLM tersebut.

Jadi kami sedang memikirkan, sebenarnya, saya dapat mengatakan bahwa kami adalah orang pertama yang memikirkan secara menyeluruh tentang apa observabilitas sebenarnya untuk semua aplikasi yang dikembangkan menggunakan model LLM. Karena saya telah menemukan banyak solusi hanya dengan melihat observasi model seperti drift dan hal-hal seperti itu. Tapi kami mencari ujung ke ujung. Ini adalah aspek yang sangat menarik karena banyak observasi aplikasi infrastruktur sejalan dengan observasi model dan hal-hal lainnya. Dan yang terakhir, jika Anda bertanya kepada CIO atau CFO mana pun, biaya LLM, seperti solusi saat ini, biaya adalah dimensi kunci lainnya. Bagaimana Anda mempertahankan biaya tersebut atau bahkan memberikan analisis apa pun tentang metrik biaya model LLM itu sendiri adalah aspek lainnya. Jadi, Anda harus melihat semuanya:performa, kekurangan, sebut saja APM untuk aplikasi LLM, lalu biayanya. Jadi ini adalah dimensi umum yang biasa Anda lihat.

Dinesh Chandrasekhar

Ruang yang sangat keren dan mengasyikkan, dan saya sangat bersemangat mengetahui apa yang akan terjadi di ruang tersebut dalam beberapa bulan mendatang. Jadi terima kasih banyak, Kresna. Ini merupakan percakapan yang sangat, sangat luar biasa. Senang memiliki Anda di acara kami. Senang berbicara tentang observasi. Saya akan mengingat tiga K Anda:Kardinalitas, Kontrol, dan Biaya. Saya pikir ini cara yang bagus, mantra yang bagus untuk melihat kemampuan observasi. Jadi terima kasih atas semua wawasannya. Menghargai Anda berada di sini. Terima kasih.

Krishna Yadappanavar

Terima kasih banyak, Dinesh. Terima kasih telah menerima saya di obrolan web Anda.