AW: [gnocchi][telemetry][ceilometer][cloudkitty] Gnocchi unmaintained

Sam Morrison sorrison at gmail.com
Tue Nov 19 22:05:52 UTC 2019


We too use ceilometer and gnocchi and it works great. The old way with
mongo simply didn't work.
Our environment is around 10k running instances and gnocchi currently has
data for 1,667,072 resources with 6,879,910 metrics.

We are happy with gnocchi and so far haven't needed to change anything but
would help contribute if there were things we needed.
Would be great if we could just maintain gnocchi as opposed to making yet
another thing.

Sam



On Wed, 20 Nov 2019 at 08:39, Matthias Runge <mrunge at matthias-runge.de>
wrote:

> On 19/11/2019 21:55, Lingxian Kong wrote:
> > On Wed, Nov 20, 2019 at 8:33 AM Matthias Runge <mrunge at matthias-runge.de
> > <mailto:mrunge at matthias-runge.de>> wrote:
> >
> >     tbh, I am surprised to see the telemetry team trying to roll back to
> >     something, which is known to cause a lot of performance issues. There
> >     were good reasons for splitting ceilometer into several components.
> >
> >
> > I understand your concerns and the team will find a better way to deal
> > with the rollback, the expected result is that it won't break anyone who
> > are using Gnocchi or other storage backend but it means much to the
> > cloud providers(like OVH and us) who are still using old version
> > Ceilometer and relying on the API.
>
>
> I assume, you haven't seen any performance issues with both Ceilometer
> or Gnocchi?
>
> >
> >     There were lots of good ideas and suggestions already shared in this
> >     thread. My proposal here would be to keep ceilometer as is (as data
> >     collecting agent) and to write missing glue to digest or send data
> to a
> >     time-series database, like InfluxDB or Prometheus (plus many more
> >     options, not mentioned here).
> >
> >
> > Does InfluxDB or Prometheus support to store samples that could be
> > leveraged for auditing or billing purpose? I'm not familiar with TSDB
> > but I got the answer NO according to the chatting with some other
> > people
>
> Billing is a complicated beast for multiple reasons. Let's look only at
> ingestion. First of all, you are right, e.g Prometheus should not be
> used in billing situations, see[1], also on [2] (same source as [1]).
>
> However, the same is true for Gnocchi and also for Ceilometer. You are
> going to loose metrics if your collection is faster than your backend
> can digest it, for Gnocchi is such behaviour documented. If you are
> looking at speed, I'd consider prometheus to be much faster than gnocchi
> and ceilometer and thus better suited for handling metrics.
>
>
>
> [1]
>
> https://github.com/prometheus/docs/blob/master/content/docs/introduction/overview.md#when-does-it-not-fit
> [2] https://prometheus.io/docs/introduction/overview/#when-does-it-not-fit
>
> >     If I remember correctly, MongoDB was deprecated because of the
> issues it
> >     caused and also because it was removed from Linux distributions,
> since
> >     there were the licensing issues.
> >
> >
> > I don't think the license change will affect the cloud that only uses
> > MongoDB as internal service backend storage unless I'm missing
> > something.
>
> You can read a bit of story on MongoDB relicensing at [3].
>
> The license change was regarding commercial use. You can find the full
> text at [4], depending on your use case, it may be valuable to ask a
> lawyer, especially, when in doubt.
>
>
>
> [3]
>
> https://hub.packtpub.com/mongodb-withdraws-controversial-server-side-public-license-from-the-open-source-initiatives-approval-process/
> [4] https://www.mongodb.com/licensing/server-side-public-license
>
> From my POV (and apparently others here in this thread as well), I'd
> take a step back and revisit
> https://storyboard.openstack.org/#!/board/205 again, in order to run
> into the same issues as in Newton cycle. I mean, if you'd want
> ceilometer from Newton, it is still there.
>
> Matthias
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191120/6e00b7c6/attachment.html>


More information about the openstack-discuss mailing list