[Telemetry][TC]Telemetry status
Tobias Urdin
tobias.urdin at binero.se
Thu Dec 19 10:41:54 UTC 2019
I can volounteer to spend time on Ceilomter and Gnocchi while I have
some mimimal knowledge on Ceilomter
and pretty much none on the Gnocchi codebase I would like to see the
project continued.
Another thing would be if Gnocchi should be moved back or if I should
somehow get in contact with the former
Gnocchi maintainers and see if we can get access to GitHub?
Best regards
On 12/19/19 2:46 AM, Rong Zhu wrote:
> I just want to know any other guys from the thread want to as
> volunteers to take over gnocchi?
>
> About Monasca, we discuss a lot in Shanghai, if users already use
> monasca, as Lingxian mentioned ceilometer has already support publish
> to monasca. but I think most of the user didn't use monasca, as a
> community you can just say use monasca, but for company want to use in
> production, add a component and the depends extra tools would be very
> very difficult, this will need many many resources to do the things.
>
> Tobias Urdin <tobias.urdin at binero.se
> <mailto:tobias.urdin at binero.se>>于2019年12月18日 周三18:00写道:
>
> https://github.com/gnocchixyz/gnocchi/issues/1049#issuecomment-555768072
>
> On 12/18/19 10:15 AM, Tobias Urdin wrote:
> > As an operator I second pretty much everything Samsaid, using
> > ceilometer-api never really worked without hand holding all the
> time.
> > We migrated over to Gnocchi as that was "the way forward" from the
> > Telemetry team and it has worked great.
> >
> > Gnocchi has a learning curve but after that it has been running
> > flawlessly even at a larger scale, just introduced more workers and
> > everything is set.
> >
> > I think the long term plan from the Telemetry team was to move
> out any
> > storage abstraction and cultivate ceilometer to a single focus
> area around
> > collecting metrics. Moving any API, transformations, storage etc to
> > another service.
> >
> > I think it's said to see Gnocchi, the actual solutions to the
> problem,
> > being unmaintained and out of the OpenStack developer ecosystem. I
> > assume there
> > is a cost to bringing it back in after it was moved out but
> maybe it's
> > something that is needed?
> >
> > While I don't have a deep understand in Gnocchi I would have no
> choice
> > but to try to spend more time learning it and fixing any issues
> that we
> > might
> > see since at this point we can't live without it, as our billing
> > providers supports the Gnocchi API, we using Heat with Gnocchi
> and Aodh
> > to autoscale etc.
> >
> > As a final note; thanks for bringing back the cpu_util metric,
> means I
> > can drop the ugly customized code that was required to bring
> that metric
> > back while
> > it was removed :)
> >
> > Best regards
> > Tobias
> >
> > On 12/18/19 5:39 AM, Sam Morrison wrote:
> >>> On 17 Dec 2019, at 10:14 pm, Thierry Carrez
> <thierry at openstack.org <mailto:thierry at openstack.org>> wrote:
> >>>
> >>> Zane Bitter wrote:
> >>>> On 15/12/19 10:20 pm, Rong Zhu wrote:
> >>>>> 1.Add Ceilometer API back
> >>>>> Since Gnocchi is out of OpenStack and is
> unmaintained, we need to add Ceilometer API back again.
> >>>> This is concerning because even the people who wrote it don't
> consider it adequate to the job. That inadequacy has been the
> source of significant reputational damage to OpenStack in the
> past, and many folks (me included) are anxious to avoid a repeat.
> >>> Yes this concerns me too, and even if we workaround the issue
> by adding Ceilo API back, I'd like to have a long-term plan to
> solve this issue. It seems there are several options on the table
> (including integrating Monasca and Ceilometer into a single stack,
> and other big-bang replacements) but it's never a one-for-one
> comparison as the solutions seem to address slightly disjoint
> problem spaces.
> >>>
> >>> I'd like to hear from more Ceilometer users. What are they
> using Ceilometer for, and what long-term plans would be
> acceptable. There is a trade-off between adopting short-term
> workarounds that reintroduce performance issues vs. undergoing a
> complex migration to the "right" way of fixing this. Like for
> example there is little point in pushing Monasca/Ceilometer stack
> integration if most users say, like Catalyst Cloud seems to say,
> that they would rather have a slow performing Ceilometer API back.
> >> Nectar Cloud has been a ceilometer user from the early days.
> Well we tried to be and couldn’t use it as ceilometer api and
> mongo db just didn’t work at our scale. Gnocchi solved all these
> issues for us and we use ceilometer/aodh/gnocchi happily in
> production for several years now.
> >> If telemetry project is going down the path of the old days it
> will mean we will either drop ceilometer all together and look at
> alternative solutions like monasca or Prometheus etc. I just can’t
> see how the old architecture of ceilometer is ever going to be usable.
> >>
> >> If there is some confidence that gnocchi publisher will be
> supported in the future we would keep using gnocchi and just
> maintain it ourselves. It’s an open source project and I was
> hoping the openstack community could keep it going. We’d be happy
> to help maintain it at least.
> >>
> >> We use ceilometer/gnocchi to collect and store all metrics from
> openstack services. We have also written some custom pollsters and
> gnocchi is quite flexible here to allow this. With these metrics
> we build reports for our users, our operators, our funders (the
> government)
> >>
> >>
> >> Please reconsider your direction much like adding cpu_util back
> in (thank you for this!)
> >>
> >> Cheers,
> >> Sam
> >>
> >>
> >>
> >>>> Telemetry is part of the TC "Approved Release" that is
> eligible for the trademark program; I think at a minimum the TC
> will want to remove the resurrected Ceilometer API from the
> "designated sections" that users are required to run to
> participate in any trademark program that includes the
> functionality in question. But I think that we should explore
> other ways of reducing the chance of anyone confusing this for a
> viable way of building a cloud, including possibly changing the
> name (Antediluvian API?) and having this part of the stack live
> outside of the official OpenStack project.
> >>> Legacy API?
> >>>
> >>> --
> >>> Thierry Carrez (ttx)
> >>>
> >>
> >
> >
>
>
> --
> Thanks,
> Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191219/ef8b9cd6/attachment-0001.html>
More information about the openstack-discuss
mailing list