Isn't prometheus an implementation and not an interface? I have "prometheus" running in my cluster, if it's not cortex, what implementation am I using?
I haven't dug into cortex even a little, but the other comments are suggesting it's API compatible but essentially claiming they're production ready because they'll give you things the OSS project won't give you out of the box, i.e. long term storage and RBAC.
> wrapping prometheus and giving you that production readyness that they're claiming the OSS project won't give you out of the box
No! Prometheus is and has been production ready for many years. Cortex is a clustered/horizontally scalable implemention of the Prometheus APIs, and Cortex has just gone production ready. Sorry for the confusion.
However, Prometheus can use different storage backends. The TSDB that it comes with is horrible.
I mean, it's workable. And can store an impressive amount of data points. If you don't care about historical data or scale, it may be all you need.
However, if your scale is really large, or if you care about the data, it may not be the right solution, and you'll need something like Cortex.
For instance, Prometheus' own TSSB has no 'fsck'-like tool. From time to time, it does compaction operations. If your process (or pod in K8s) dies, you may be left with duplicate time series. And now you have to delete some (or a lot!) of your data to recover.
Prometheus documentation, last I checked, even says it is not suitable for long-term storage.
The TSDB it uses is actually pretty state of the art. I think your pain point is more that it's designed for being used on local disk, but that doesn't mean it isn't possible to store the TSDB remotely. In fact, this is exactly how Thanos works.
The docs say Prometheus is not intended for long term storage because without a remote_write configuration, all data is persisted locally, and thus you will eventually hit limits on the amount that can be stored and queried locally. However, that is a limitation on how Prometheus is designed, not how the TSDB is designed, and which can be overcome by using a remote_write adapter.
Yes, Prometheus is an implementation - the HN text has a limited number of words, so I thought "Prometheus implementation" conveyed the fact Cortex was trying to be a 100% API compatible implementation of Prometheus, but with scalability, replication etc
Yes, you're running the Prometheus server. But what Cortex is a Prometheus API compatible service that horizontally scales and has multi-tenancy and other things built in.
ownagefool|6 years ago
- The OSS product
- The Storage Format (I guess)
- The Interface for pulling metrics (https://github.com/OpenObservability/OpenMetrics)
I haven't dug into cortex even a little, but the other comments are suggesting it's API compatible but essentially claiming they're production ready because they'll give you things the OSS project won't give you out of the box, i.e. long term storage and RBAC.
Looks like a good thing.
netingle|6 years ago
No! Prometheus is and has been production ready for many years. Cortex is a clustered/horizontally scalable implemention of the Prometheus APIs, and Cortex has just gone production ready. Sorry for the confusion.
outworlder|6 years ago
However, Prometheus can use different storage backends. The TSDB that it comes with is horrible.
I mean, it's workable. And can store an impressive amount of data points. If you don't care about historical data or scale, it may be all you need.
However, if your scale is really large, or if you care about the data, it may not be the right solution, and you'll need something like Cortex.
For instance, Prometheus' own TSSB has no 'fsck'-like tool. From time to time, it does compaction operations. If your process (or pod in K8s) dies, you may be left with duplicate time series. And now you have to delete some (or a lot!) of your data to recover.
Prometheus documentation, last I checked, even says it is not suitable for long-term storage.
ecnahc515|6 years ago
The docs say Prometheus is not intended for long term storage because without a remote_write configuration, all data is persisted locally, and thus you will eventually hit limits on the amount that can be stored and queried locally. However, that is a limitation on how Prometheus is designed, not how the TSDB is designed, and which can be overcome by using a remote_write adapter.
sagichmal|6 years ago
The TSDB in Prometheus since 2.0 is excellent for its use case.
netingle|6 years ago
cat199|6 years ago
CNCF's Cortex v1.0: scalable, fast Prometheus API implementation ready for prod (grafana.com)
saves 1 char.
gouthamve|6 years ago