[HN Gopher] Beyond Elk: Lightweight and Scalable Cloud-Native Lo...
       ___________________________________________________________________
        
       Beyond Elk: Lightweight and Scalable Cloud-Native Log Monitoring
        
       Author : xzhuang1984
       Score  : 15 points
       Date   : 2025-04-28 20:34 UTC (2 hours ago)
        
 (HTM) web link (greptime.com)
 (TXT) w3m dump (greptime.com)
        
       | firesteelrain wrote:
       | Any reason to use this like in Azure over their cloud native
       | options such as with AKS that has fluentd built into the ama-pod?
       | It already sends logs to Azure Monitor/LogA. Azure Managed
       | Grafana can take in Kusto queries. AMA can monitor VMs. Further
       | you can use DCE/DCRs for custom logs. Azure provides Azure native
       | ElasticSearch too. It seems to own this market.
       | 
       | You can predictably control costs and predict costs with these
       | models.
        
       | chreniuc wrote:
       | How does it compare to openobserve?
        
       | atombender wrote:
       | How does Greptime handle dynamic schemas where you don't know
       | most of the shape of the data upfront?
       | 
       | Where I work, we have maybe a hundred different sources of
       | structured logs: Our own applications, Kubernetes, databases,
       | CI/CD software, lots of system processes. There's no common
       | schema other than the basics (timestamp, message, source,
       | Kubernetes metadata). Apps produce all sorts JSON fields, and we
       | have thousands and thousands of fields across all these apps.
       | 
       | It'd be okay to define a small core subset, but we'd need a
       | sensible "catch all" rule for the rest. All fields need to be
       | searchable, but it's of course OK if performance is a little
       | worse for non-core fields, as long as you can go into the schema
       | and explicitly add it in order to speed things up.
       | 
       | Also, how does Greptime scale with that many fields? Does it do
       | fine with thousands of columns?
       | 
       | I imagine it would be a good idea to have one table per source.
       | Is it easy/performant to search multiple tables (union ordered by
       | time) in a single query?
        
       | client4 wrote:
       | For logs I'd be more likely to choose https://www.gravwell.io as
       | it's log agnostic and I've seen it crush 40Tb/s a day, whereas it
       | looks like greptime is purpose-tuned for metrics and telemetry
       | data.
        
       | reconnecting wrote:
       | I'm always skeptical toward software companies with an outdated
       | year in the footer.
        
       ___________________________________________________________________
       (page generated 2025-04-28 23:00 UTC)