| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 <2023> 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Epics Archiver Online Status Question |
| From: | Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> |
| To: | Ralph Lange <ralph.lange at gmx.de> |
| Cc: | EPICS Tech Talk <tech-talk at aps.anl.gov> |
| Date: | Fri, 5 May 2023 07:58:01 -0700 |
On 5/4/23 02:16, Ralph Lange via Tech-talk wrote:
It all depends on the viewpoint... I would consider the archiving services part of the controls infrastructure, just like file servers, time servers, DNS servers, switches, and all the rest that is necessary to run the control system. That moves the archiver health check to the infrastructure monitoring system (something like Nagios/Icinga). These systems usually have out-of-the-box much better support for redundancy, notifications, planned downtime management and status aggregation compared to EPICS.
Yet another specialist service which is administered differently, and doesn't integrate well with other components of our ecosystem. eg. Nagios "archiving" and plotting are primitive in comparison with eg. archiver appliance and phoebus. Personally, I wish that I had been more successful in convincing IT folks to use EPICS for infrastructure monitoring. Excepting perhaps "DNS servers", we have drivers for the data points mentioned. And the "configuration before compilation" mantra seems like a good fit for people who live in a pile of configuration files.
Conceptually, I find having the IOC use a different network protocol to check for the status of one of its clients a bit awkward. Cheers, ~Ralph