influxdb-apply
opstrace
Our great sponsors
influxdb-apply | opstrace | |
---|---|---|
1 | 8 | |
0 | 1,153 | |
- | - | |
0.0 | 9.9 | |
about 4 years ago | over 2 years ago | |
Python | TypeScript | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
influxdb-apply
-
Launch HN: Opstrace (YC S19) – open-source Datadog
Yes, `apply` is hard. It's just as hard as deploying, maintaining, and turning down a service. When adding an `apply` command to a devops tool, the tool authors must think through the entire lifecycle of their service in the user's workflow and make it work well.
The tool creators are the ones with the knowledge to figure these things out. If they don't provide `apply`, then users must research and experiment and learn by making mistakes. This is a colossal waste of effort. Users end up with brittle poorly-documented scripts to do all the things that `apply` would do. These scripts cause ongoing waste of engineering effort, customer frustration from downtime, and lost business growth and revenue.
I spent several weeks making `apply` commands for InfluxDB [0] and Grafana. This proved extremely difficult for Grafana because of deficiencies in its API. Both InfluxDB and Grafana need some work to make them fit into a modern infrastructure-as-code ops environment. Grafana's cofounder and product lead were not interested in my feedback [1] [2].
[0] https://github.com/cozydate/influxdb-apply
[1] https://news.ycombinator.com/item?id=23136582
[2] https://news.ycombinator.com/item?id=23233468
opstrace
- Launch HN: ContainIQ (YC S21) – Kubernetes Native Monitoring with eBPF
-
What is everyone using for monitoring and logging
Never had any luck maintaining monitoring stacks over time, until I found https://opstrace.com
-
Kubernetes Podcast episode 156: Opstrace, with Sebastien Pahl
Sebastien Pahl is a pioneer of container technology, building the predecessor to Docker as a co-founder of Dotcloud. After working at some big tech companies, he's back to the startup life as co-founder of Opstrace, a fully open source observability distribution, built on top of the tools you know and love.
- Opstrace: self hosted alternative to datadog; handles administrator of exporters and Prometheus for you.
-
Launch HN: Opstrace (YC S19) – open-source Datadog
Jan-Philip from Opstrace here, good morning. Would love to hear more, after all, when you know more :-). By the way, we had been asked about VictoriaMetrics before, here: https://github.com/opstrace/opstrace/discussions/98.
What are some alternatives?
loki - Like Prometheus, but for logs.
Cortex - Cortex: a Powerful Observable Analysis and Active Response Engine
veneur - A distributed, fault-tolerant pipeline for observability data
cortex - A horizontally scalable, highly available, multi-tenant, long term Prometheus.
ApplicationInsights-node.js - Microsoft Application Insights SDK for Node.js
pixie - Instant Kubernetes-Native Application Observability
kiali-ui - Frontend part of Kiali (use github.com/kiali/kiali to report issues)
cilium - eBPF-based Networking, Security, and Observability