Episódio 7 do Smart Talk:Navegando pela cardinalidade, controle e custos na observabilidade

Discutimos a observabilidade e o espaço complementar do AIOps algumas vezes nesta série, mas desta vez, damos um mergulho mais pragmático no tópico para entender a mentalidade do comprador. O que um CIO de uma organização deve procurar quando procura uma solução de observabilidade no mercado? Junte-se a nós neste episódio enquanto Dinesh Chandrasekhar, analista-chefe e fundador da Stratola, fala com Krishna Yadappanavar, CEO da Kloudfuse. Krishna explica a observabilidade através das lentes de três fatores – Cardinalidade, Controle e Custos.
Esses 3 Cs são fundamentais para compreender e gerenciar dados de observabilidade cada vez maiores. Esses fatores não são importantes apenas para gerenciar os dados, mas também para aproveitar os dados e metadados para análises adicionais.
Um novo desenvolvimento no campo da observabilidade é a observabilidade do modelo, especialmente os LLMs que impulsionam a IA generativa. Os 3 Cs também se aplicam a este caso de uso emergente.

Alguns dos tópicos abordados neste episódio do Smart Talk são:

• Potencial dos dados de observabilidade
• Proliferação de ferramentas
• Superando dados de observabilidade isolados
• Considerando os metadados
• Informações sobre custos

Convidado
Krishna Yadappanavar, CEO, Kloudfuse
Krishna Yadappanavar é cofundador e CEO da Kloudfuse, uma plataforma unificada de observabilidade. Anteriormente, ele foi cofundador da SpringPath, garantindo US$ 94 milhões em financiamento e levando a empresa a uma aquisição de US$ 320 milhões pela Cisco. Com mais de 20 patentes, Krishna impactou significativamente as tecnologias de dados, virtualização e armazenamento na Veritas, Commvault, EMC, VMware e Cisco. Ele foi coautor do VMFS da VMware e projetou componentes críticos da pilha de virtualização de armazenamento para o ESX Server. Além disso, Krishna aconselha e investe em startups emergentes em dados, virtualização, nuvem, segurança e IA/ML, contribuindo para visão, estratégia de produto, engenharia e esforços de entrada no mercado.

Anfitrião:  Dinesh Chandrasekhar é um evangelista de tecnologia, um líder inovador e um analista experiente do setor de TI. Com quase 30 anos de experiência, Dinesh trabalhou em software empresarial B2B, bem como em produtos SaaS, entregando e comercializando soluções sofisticadas para clientes com arquiteturas complexas. Ele também definiu e executou estratégias GTM altamente bem-sucedidas para lançar vários produtos de alto crescimento no mercado em várias empresas como LogicMonitor, Cloudera, Hortonworks, CA Technologies, Software AG, IBM etc. Dinesh possui MBA pela Universidade de Santa Clara e mestrado em Aplicações de Computador pela Universidade de Madras. Atualmente, Dinesh dirige sua própria empresa, Stratola, uma empresa de consultoria de estratégia de negócios e serviços de marketing full-stack com foco no cliente.

Recursos
Episódio 6 do Smart Talk:AIOps e o futuro do monitoramento de TI
Episódio 5 do Smart Talk:Desagregação da pilha de observabilidade
Episódio 4 do Smart Talk:dados em tempo real e bancos de dados vetoriais
Episódio 3 do Smart Talk:Pipelines de dados modernos e LLMs
Episódio 2 do Smart Talk:A ascensão dos aplicativos GenAI com dados em movimento
Episódio 1 do Smart Talk:O cenário do ecossistema de dados em movimento
Veja o mapa do ecossistema de dados em movimento aqui
Saiba mais sobre dados em movimento no RTInsights aqui

Transcrição
Dinesh Chandrasekhar

Olá e seja bem-vindo a este episódio do Smart Talk, uma série de liderança Data in Motion. E neste episódio temos um convidado especial, Krishna Yadappanavar. Ele é o CEO da Cloud Fuse. Ele conhece bem o ecossistema de startups. Ele é um empreendedor em série. Ele construiu algumas empresas antes disso e, por isso, damos as boas-vindas a Krishna para ter esta conversa sobre observabilidade, que é, novamente, um tema favorito nesta série. 

Krishna Yadappanavar

Obrigado.

Dinesh Chandrasekhar

Então, Krishna, como forma de se apresentar, por que você não nos conta sobre o Kloudfuse e sua motivação para abrir a empresa?

Krishna Yadappanavar (01:01):

Ok, absolutamente. Obrigado, Dinesh. Obrigado pela calorosa introdução. Olá pessoal, meu nome é Krishna. Sim, moro no Vale há quase duas décadas e tenho trabalhado com várias startups e grandes empresas. O nome da fama é como VMware quando era uma startup. Entrei e depois vi crescer de literalmente perto de um milhão de ERR para uma empresa de 64 mil milhões e estive associado a diferentes tecnologias relacionadas com dados, seja na escrita de sistemas de ficheiros, sistemas distribuídos, bases de dados ou OLAP ou OLTP. Ok, ao longo desta jornada o que percebi é que os dados são o segredo de todos os insights, seja no lado da análise do produto ou no fornecimento de uma solução como virtualização ou no fornecimento de uma solução como backup ou recuperação de desastres. Tendo feito minha startup, Springpath, que estava na hiperconvergência, tentando reunir a convergência de armazenamento, rede e segurança em uma caixa que vendi para a Cisco.

E depois de passar algum tempo na Cisco, fiquei pensando quais serão as próximas grandes tendências que virão? Isso foi no início de 2020. Me deparei com algumas tendências, como algumas das tendências relacionadas a como os dados em relação a um desenvolvedor DevOps ou SecOps estão crescendo exponencialmente. Como as novas tendências nos modelos de IA e LLM de aprendizado de máquina na época em que os modelos LLM estavam nos estágios iniciais vão perturbar o mercado? E então, à medida que o cérebro humano começa a pensar e a reagir a certos incidentes, queremos que as máquinas atuem de maneira semelhante. Esses foram alguns dos problemas que encontramos e na interseção dos três, descobri que, ei, resolver o problema não apenas da observabilidade, mas da observabilidade mais análise e automação, além dos dados, que são focados nos desenvolvedores e o DevOps é muito crítico. Isso levou ao início do Kloudfuse – um levou ao outro e agora somos uma equipe de cerca de 40 pessoas.

Dinesh Chandrasekhar (03:16):

Bem, parabéns e este é um ótimo começo. Então, desejo-lhe boa sorte nessa jornada. Falando em observabilidade, isso não foi algo que aconteceu ontem. Também trabalhei nesse espaço por um bom tempo e o conceito de observabilidade evoluiu ao longo dos anos. Então, originalmente, há 10, 12 anos, as pessoas estavam entusiasmadas em falar sobre monitoramento de infraestrutura, monitoramento de rede e tudo mais, e então, lentamente, uma coisa levou à outra e então surgiram recursos de monitoramento de nuvem e monitoramento de contêineres que foram adicionados. E hoje temos esta noção de observabilidade que é bastante popular. A maioria das empresas que costumavam promover o monitoramento agora são empresas de observabilidade. E eu sei que você começou de novo no espaço da observabilidade querendo criar a diferença. Como você descreveria essa evolução? O que era antes comparado com o que temos hoje? Como você tem visto essa evolução?

Krishna Yadappanavar (04:09):

Sim, ótima pergunta. Jantar. Eu já vi isso, quero dizer, como desenvolvedor, escrevendo um aplicativo monolítico rodando em máquinas físicas. Então eu vi o advento da virtualização, seja como VMware ou Hyper-V ou as tecnologias de virtualização de código aberto e a conteinerização surgiu. Então, se você olhar para os principais problemas quando se trata de dados para observação, à medida que essas avaliações evoluíram, vimos que os atributos associados aos dados continuam aumentando, e quando você pega o produto cartesiano desses atributos, ele se torna realmente grande, na ordem de vários milhões a bilhões. O que eles chamam de cardinalidade associada a essa cardinalidade é o volume de dados. À medida que o volume de dados aumenta, as pessoas desejam transformar os dados A em dados B para obter melhores análises. Eles desejam automatizar determinados fluxos de trabalho com base nos dados.

Eles querem dividir os dados para que possam fornecer insights melhores. Resumindo, à medida que o volume de dados aumenta a forma tradicional de, ei, eu estava monitorando o chamado à medida que o conhecido vai embora, que é o monitoramento tradicional. Então você está olhando para as incógnitas conhecidas, que é o início da observabilidade e há as incógnitas completamente desconhecidas onde você não sabe nada e é jogado em vários terabytes a petabytes de dados e você tem que dissecar esses dados e chegar à falta de uma palavra melhor onde exatamente está o problema, como ele está correlacionado ao incidente, qual é a análise da causa raiz, qual é a análise de impacto. Portanto, enquanto os desenvolvedores escrevem código, essa complexidade e mais e mais serviços surgirão. Esta complexidade vai aumentar cada vez mais e, portanto, este continua a ser um espaço em evolução onde surgem novos desafios.

Dinesh Chandrasekhar (06:14):

Fantástico. Portanto, a observabilidade é obviamente um problema difícil de resolver. Eu adoraria explorar por que isso acontece? Mas acho que você também tocou nisso um pouco agora, mas também temos um mercado lotado com uma dúzia de fornecedores por aí que estão dizendo:resolvemos essa parte da observabilidade e esse tipo de observabilidade e tudo mais, mas ainda há uma busca pela solução ideal. Portanto, todo CIO com quem converso está sempre em busca de uma solução mágica que resolva seus problemas. Por que é que? Existe uma lente diferente através da qual você deve olhar para entender por que existe um desejo diferente de obter a solução ideal?

Krishna Yadappanavar (07:04):

Então, como eu estava aludindo antes, deixe-me recuar um pouco, certo? O que o cliente procura quando pensa em uma solução de observação ideal? Vamos começar pelo problema. Classifico este problema como os três Cs – a Cardinalidade, o Controle e o Custo. Deixe-me passar para o próximo nível de detalhes. O que esses três Cs significam? Cardinalidade, é tudo sobre como temos certos dados, seja um ponto métrico complicado ou uma linha de registro ou um evento ou um traço ou um intervalo proveniente do rastreamento do seu distribuidor ou do perfil de um perfil contínuo, eles são anexados com adicionais, por falta de uma palavra melhor, rótulos ou tags. Quando você considera o produto cartesiano dos valores potenciais que esses rótulos podem assumir, ele crescerá muito, muito alto. Portanto, agora cada ponto de dados precisa ser associado às suas tags.

Então, vamos chamar tags de metadados. E então há dados. Esquemas diferentes têm problemas diferentes. Alguns são pesados ​​em metadados. Quando você vai para o site da matriz, quando você chega aos logs e aos spans como o rastreamento distribuído, eles são como dados pesados, mas na verdade, é o tremendo aumento no volume dos dados de observabilidade por causa da cardinalidade. Hoje em dia tenho visto a tendência inversa. Quero dizer, antigamente as pessoas pensavam:Ei, deixe-me enviar meus dados para um portal SaaS e então o fornecedor de SaaS gerenciaria todos esses dados. Mas quando falo com o CTO, o CIO, o chefe de engenharia, os desenvolvedores, os arquitetos e até mesmo o CFO, eles pensam:deixe-me ter o controle dos meus dados. O que eles querem dizer com isso? Há uma tendência inversa de que tenho tantos dados por vários motivos, seja a saída no custo do risco, os aspectos de segurança ou o volume dos dados em si.

Eles não querem enviar esses dados para fora de sua VPC e há outro ângulo para isso. Eles querem trazer todas as interfaces possíveis que possam imaginar, seja para um tipo de interface de observatório tradicional, como criar seus painéis, alertas, SLOs ou quaisquer funções analíticas que possam ser escritas em um SQL tradicional ou GraphQL ou que possam ser avançados, como trabalhos Spark, para executar algumas análises sobre os dados de observabilidade, porque a observabilidade se tornou esse pilar fundamental. Isso significa que eles precisam possuir os dados. Os dados não devem sair da VPC. Quando digo os dados, os dados que estão sendo ingeridos, os dados que estão sendo consultados e os dados que estão sendo analisados ​​e, por último mas não menos importante, é o custo. Se você for a qualquer fornecedor, seja um fornecedor comercial de SaaS tradicional ou um componente de código aberto, há muitas soluções de código aberto por aí. O custo da infraestrutura, o custo do fornecedor é diretamente proporcional ao volume de dados, diretamente proporcional ao número de consultas e diretamente proporcional ao número de usuários. Essas três coisas são os problemas que uma organização tradicional que procura uma solução ideal, uma solução ideal de observabilidade está procurando

Dinesh Chandrasekhar (10:24):

Cardinalidade, controle e custos. Acho que adoro isso. Os três Cs são uma ótima maneira de observar o espaço de observabilidade e como você infere o que é importante para os usuários reais e assim por diante. Falando em custos, já que tocamos nisso, quero te fazer essa pergunta também. Pela minha experiência pessoal, quando conversei com clientes que procuram uma solução de observabilidade, o que eles costumam reclamar é:Ei, tenho pelo menos oito a 10 ferramentas diferentes em cada departamento que possuo. Estou analisando talvez 30 a 40 ferramentas em toda a organização hoje. Já estou tendo muitos custos para pagar essas licenças ano após ano. “Por que eu quero mais uma solução de observabilidade” é uma reação que eu costumava receber, certo? Então, vou fazer a mesma pergunta para você agora que você tocou no aspecto do custo. Como você aborda essa questão com um CIO e os convence ou diz por que isso é melhor do que ter 30 ou 40 ferramentas diferentes?

Krishna Yadappanavar (11:23):

Ok, ótima pergunta. Então, para responder a essa pergunta, vamos começar com o problema de por que há uma proliferação de ferramentas. Então, se você olhar para todo o ecossistema, tradicionalmente alguns fornecedores, se eu considerar os fornecedores comerciais, eles eram muito bons em determinados fluxos. Se você for aos logs, poderá pensar no Splunk. Se você pensa em métricas, pensa no Datadog. Depois, dentro do Google e de todos os FANGs do mundo. Todo esse movimento de código aberto começou, especialmente com o advento do Kubernetes, depois vieram coisas como Prometheus, OpenTelemetry e outros enfeites.

E há toda essa mudança que está acontecendo e migrando para a solução baseada em código aberto. O que isso significa? Isso significa que os desenvolvedores, os arquitetos e o pessoal do DevOps desejam ingerir seus dados de observabilidade em um formato aberto. Ou seja, mesmo que eu escolha qualquer instrumentação para instrumentar meu código ou coloque qualquer agente para coletar meus dados, isso deve ser cem por cento compatível com código aberto. É por isso que quando os fornecedores comerciais também começaram a colocar seus agentes em código aberto, no lado da consulta, eles querem que toda a visualização, o painel, os alertas – todos esses recursos sejam conduzidos pelas linguagens de consulta de código aberto. É por isso que o surgimento do PromQL, LockQL, TraceQL, OpenTelemetry, agora eles estão tentando outra linguagem de consulta de código aberto.

 Então agora você está neste mundo onde tem muitas opções. Os clientes já escolheram determinados fluxos, determinados fornecedores.

Depois, há um movimento de código aberto e equipes diferentes usam infraestruturas diferentes. Alguns são baseados em Kubernetes, alguns são baseados em serverless, alguns são baseados em ECS, Fargate e outros enfeites. Então isso é agregar outra dimensão e para chegar à velocidade e agilidade de toda a entrega do produto, o CI/CD evoluiu nessa interseção para resolver os problemas com muita rapidez. Eles tentam procurar a solução pontual e, portanto, acabam escolhendo a solução mais pontual. Foi então que, como solução de observabilidade ideal, se eu iniciasse minha pilha de observabilidade para minha empresa, daria um passo atrás e veria, ei, se eu quiser reduzir meu MTTR e MTTD, preciso coletar todos os fluxos finais dos dados de observabilidade. Devo ir para n fornecedores diferentes e escolha n fluxos diferentes, ou vou para um data lake de observabilidade onde posso reunir todos os fluxos para que a correlação, as funções avançadas como detecção de valores discrepantes, anomalias e causalidade se tornem relativamente mais fáceis? Essa seria uma solução ideal onde você pode consolidar tudo em um data lake onde você pode preservar seus dados dentro de suas instalações.

Dinesh Chandrasekhar (14:18):

Fantástico. E eu também gostaria de acrescentar que o custo da proliferação de ferramentas, eu concordo em grande parte porque os desenvolvedores querem construir suas próprias coisas e também adicionaram muitas ferramentas de código aberto ao mix, mas também são compras em nível de departamento. Então, um departamento de TI sente que posso resolver esse problema porque deixe-me conseguir uma solução bandaid, deixe-me comprar essa ferramenta na prateleira e usá-la. E então, com o tempo, eles perceberam que adicionaram mais uma ferramenta ao arsenal e sem perceber que não estão olhando para as árvores na floresta. Portanto, as conversas do CIO são sempre interessantes e sobre como você pode compactar ou reduzir o número de ferramentas que você tem em toda a empresa e ter uma plataforma de observabilidade analisando todos os departamentos, analisando aplicativos, contêineres de infraestrutura e outros enfeites. 

Krishna Yadappanavar (15:08):

Absolutamente. Quero acrescentar que agora diferentes personas na empresa também estão analisando os mesmos dados. Assim como os desenvolvedores de DevOps, todos os arquitetos estão analisando os dados de observabilidade em relação à infraestrutura, aplicativos de conteinerização e outros enfeites. Usando os mesmos logs. O pessoal do SecOps está tentando dissecar os dados em busca de segurança e ameaças. Observando os dados semelhantes provenientes dos logs ou dos rastreamentos. Até o pessoal do DataOps está pensando:Ei, quão boas são minhas operações de dados? E agora, com o advento do LLM, até mesmo o pessoal do LLM Ops está analisando dados semelhantes para fazer seu tipo de análise. Portanto, há outra consolidação que precisa acontecer. Isso é algo que eu procuraria em uma solução de observabilidade ideal. Como faço para trazer todas as diferentes personas de uma organização para que elas possam aproveitar os dados do mesmo chamado data lake.

Dinesh Chandrasekhar (16:05):

Verdadeiramente o proverbial painel de vidro único pelo qual todos temos nos esforçado. Então é uma coisa boa. Então, quero abordar outra coisa que você mencionou brevemente ao explicar a resposta anterior, que era sobre a redução do MTTR, certo? Portanto, como ponto crucial da observabilidade, trata-se não apenas de solucionar problemas, mas também de reduzir o MTTR, reduzir o ruído de alerta e também esses tipos de métricas. Portanto, isso definitivamente evita que SREs e operações de TI tenham que dividir os cabelos e descobrir onde está o problema e tudo isso como um requisito fundamental para resolver isso. Você precisa de acesso a eventos em tempo real enquanto eles acontecem. Se houver um log inserido em um aplicativo específico ou servidor específico sobre uma atividade maliciosa ou algo parecido, você precisará acessar esse evento imediatamente para poder entender onde está essa anomalia, o que está acontecendo em sua infraestrutura, por que esse pico específico em um thread de memória específico ou algo assim.

Então você precisa descobrir isso e, para que isso aconteça, você também precisa ter a capacidade de ingerir tudo isso em tempo real. Imediatismo dos dados, que é um dos meus termos favoritos no último ano, tenho falado sobre isso, e a atualização dos dados é de suma importância aqui. É disso que estamos falando, quão atualizados são os dados, é quão rápido você pode resolver aquele problema específico ou talvez até mesmo evitar algo que está prestes a acontecer neste contexto específico de observabilidade, especialmente quando você está falando sobre centenas e milhares de servidores que você está monitorando e tudo mais, ou onde você identifica, dizendo, é aqui que está o problema em termos de fazer com que os dados sejam tão atualizados quanto possível ou não. Depende em grande parte dos mecanismos de ingestão? Porque você falou sobre TEL e outros tipos de técnicas de instrumentação e tudo mais. Então, de que outra forma você pensaria sobre isso ou olharia a partir desta perspectiva de quão rapidamente posso obter acesso a dados em tempo real?

Krishna Yadappanavar (18:03):

Ok, outro grande aspecto da equipe de observação, você está absolutamente certo, Danesh. Portanto, a principal dimensão em que os dados observativos são consumidos é a rapidez com que posso obtê-los, o momento em que os dados saem da fonte dos dados, seja seu aplicativo, seus componentes de infraestrutura ou sua plataforma, como componentes de código aberto e coisas assim. Então, para isso, se você observar como a indústria evoluiu nos últimos cinco a dez anos, os serviços de streaming em tempo real e os bancos de dados em tempo real surgiram. Se você olhar para as soluções tradicionais de observ, quero dizer que elas não poderiam aproveitar essas funcionalidades porque a tecnologia era relativamente mais antiga. Assim, com o advento do streaming em tempo real e dos bancos de dados em tempo real, você pode acessar os dados o mais rápido possível. Então essa é a medida do que é chamado de atualização dos dados desde o momento em que eles saem do aplicativo até que sejam facilmente consultáveis, isso é tudo que importa.

Depois, há aquele aspecto de, ei, eu tenho todos os dados. Como compartimentalizar esses dados? Como encontro os padrões relevantes necessários para chegar à causa raiz é o próximo conjunto de problemas. Isso significa que devo ser capaz de transformar os dados de um dado em outro. Ei, estou recebendo uma série de registros. Posso ver rapidamente uma métrica dos registros? Estou recebendo uma série de vãos. Posso examinar algum atributo nesse intervalo ou um rastreamento para analisar esses dados? Porque esses atributos normalmente são correlacionados e é assim que acontece a depuração. Então essa é a próxima dimensão. E então a terceira dimensão é a análise avançada. Além desses dados, posso trazer algumas estatísticas interessantes ou modelos de linguagem grandes para analisar os dados e encontrar o que é chamado de outliers em meu sistema?

Posso encontrar as anomalias no meu sistema? Ok, posso analisar o aspecto da sazonalidade dos meus dados? Posso prever meus dados com base no que vi no passado? O aspecto sazonal dos dados? Então, tudo isso é o que chamo de pacote de análise avançada. Portanto, quando você pensa na solução geral após a atualização dos dados ser resolvida, você precisa pensar nos dados como uma unidade de um bloco e, em seguida, como cada bloco pode ser ajustado e, em seguida, definir a função analítica. E então a coisa natural que precisaremos é, ei, já analisei isso uma vez, posso automatizar? Isso se torna a extensão natural de tudo. É por isso que, junto com o problema dos três Cs, vimos clientes perguntando como posso observar, analisar e automatizar meus dados de observação.

Dinesh Chandrasekhar (20:57):

Muito legal. Muito legal. E então, como parte de sua resposta, você também mencionou a palavra mágica LLMs, grandes modelos de linguagem. Quero dizer, hoje em dia você não pode conversar sem falar sobre GenAI LLMs. Estou feliz que você tenha mencionado isso, porque eu definitivamente poderia perguntar sobre isso, que é a observabilidade do LLM. Parece que esse é um espaço emergente, visto que temos uma proliferação de LLMs em todos os lugares e as pessoas estão lutando para entender seu desempenho e assim por diante. Então conte-nos sobre isso. Parece que Kloufuse também está construindo algo nessa frente, certo? Então conte-nos mais sobre isso.

Krishna Yadappanavar (21:32):

Quero dizer, sim. Quero dizer, fundamentalmente, os modelos LLM estão sendo implantados em vários casos de uso, certo? Quanto à falta de palavra melhor. O dinamismo dos dados muda, principalmente no mundo da observabilidade, os dados são muito dinâmicos. Construir o modelo LLM certo para realizar certas operações é sempre difícil. Portanto, analisamos o problema de duas maneiras. Como posso aproveitar certos modelos LLM sobre os dados de observabilidade existentes, que estão sendo consumidos por todas as diferentes pessoas de que falei, sejam DevOps ou SecOps ou caras de DataOps ou LLMOps. Esse é o único aspecto disso. E há o outro aspecto de, ei, estou desenvolvendo um aplicativo onde o LLM é um componente muito, muito crítico. Como posso observar a observabilidade completa de um aplicativo que está produzindo os dados, que estão sendo alimentados no LLM, e há muitos consumidores que estão consumindo esses dados desses modelos LLM.

Então estamos pensando, na verdade, posso dizer que somos os primeiros a pensar de ponta a ponta sobre qual é a verdadeira observabilidade para todas as aplicações que são desenvolvidas usando os modelos LLM. Porque encontrei muitas soluções apenas olhando para a observabilidade do modelo, como deriva e coisas assim. Mas estamos olhando de ponta a ponta. Esse é um aspecto muito interessante porque grande parte da observabilidade do aplicativo de infraestrutura acompanha a observabilidade do modelo e o resto. E por último, mas não menos importante, se você perguntar a qualquer CIO ou CFO, o custo do LLM, como as soluções atuais, o custo é outra dimensão importante. Como você mantém esse custo ou até mesmo fornece análises sobre as métricas de custo dos próprios modelos LLM é outro aspecto disso. Portanto, você precisa analisar tudo:desempenho, falta de desempenho, vamos chamar de APM para aplicativos LLM, e depois o custo. Portanto, essas são as dimensões típicas que você observaria.

Dinesh Chandrasekhar

Espaço muito legal e emocionante e estou definitivamente animado para saber o que está por vir naquele espaço nos próximos meses. Então, muito obrigado, Krishna. Esta foi uma conversa muito, muito maravilhosa. Adorei ter você no nosso programa. Adoro falar sobre observabilidade. Vou me lembrar dos seus três Cs:Cardinalidade, Controle e Custos. Acho que é uma ótima maneira, um ótimo mantra de observar a observabilidade. Então, obrigado por todos os insights. Agradeço por você estar aqui. Obrigado.

Krishna Yadappanavar

Muito obrigado, Dinesh. Obrigado por me receber em seu chat na web.