there are many questions .... read below: - It can be installed in such a way that in case of an OS / HW, in case of other error or if the software stops on another machine, the given task is high, the availability of the service itself is high. - It should be possible to write accessories according to your needs. - The system has detailed technical and programmable documentation - Database and data storage capabilities are required to be able to handle about 25k + host and their associated 1-3m measurements - You need to be able to work with older monitoring solutions - The system should be able to track changes in the operated systems without human intervention (eg new LUNs, emerging-terminating VMs, ports, etc.) - Generate manual and scheduled reports from measured data - Hosts, measurements, alarms can be created from pre-made templates - In case of load, the situation can be resolved by involving new servers - Existing configured hosts can be copied) as for template) - Settings should be possible on both sides, but preferably limited to one page (either client or server side) - It should be possible to generate an alarm from several input data - eg a measurement is OK on server A, but not on server B, then the alarm should be different than if, for example, an error occurs in both cases - Hierarchical federation (Island - center structure) - There must be one-way communication between the island and the center, only towards the island or only from the island. Communication from the island is an advantage - You can flexibly set which type of information (eg measurements, even per host) to keep for how long - Possibility to export data - Time-based automation option (preferably not textually defined actions in action plans) - Is it possible to create individual reports. - Two levels of alerts, so systems under deployment should not appear in front of the Help Desk, but should be visible to operators on demand. - How to "tag" 1-1 alarms individually, but even from a template, to which group the given alarm belongs. For example: Linux server CPU load Linux group, B linux server CPU load DBA group, etc.…
Stuart Clark a következőt írta (2021. augusztus 21., szombat, 22:34:55 UTC+2): > On 21/08/2021 21:19, Henriett Braunné Bokor wrote: > > Hello! > > > > Our company is currently piloting the Prometheus application. > > During the pilot, we had a couple of questions, the answers to which > > would greatly help our work. Could you possibly help with any info, docs? > > - It can be installed in such a way that in case of an OS / HW, in > > case of other error or if the software stops on another machine, the > > given task is high, the availability of the service itself is high. > > - It should be possible to write accessories according to your needs. > > - The system has detailed technical and programmable documentation > > - Database and data storage capabilities are required to be able to > > handle about 25k + host and their associated 1-3m measurements > > - You need to be able to work with older monitoring solutions > > - The system should be able to track changes in the operated systems > > without human intervention (eg new LUNs, emerging-terminating VMs, > > ports, etc.) > > - Generate manual and scheduled reports from measured data > > - Hosts, measurements, alarms can be created from pre-made templates > > - In case of load, the situation can be resolved by involving new servers > > - Existing configured hosts can be copied) as for template) > > - Settings should be possible on both sides, but preferably limited to > > one page (either client or server side) > > - It should be possible to generate an alarm from several input data - > > eg a measurement is OK on server A, but not on server B, then the > > alarm should be different than if, for example, an error occurs in > > both cases > > - Hierarchical federation (Island - center structure) > > - There must be one-way communication between the island and the > > center, only towards the island or only from the island. Communication > > from the island is an advantage > > - You can flexibly set which type of information (eg measurements, > > even per host) to keep for how long > > - Possibility to export data > > - Time-based automation option (preferably not textually defined > > actions in action plans) > > - Is it possible to create individual reports. > > - Two levels of alerts, so systems under deployment should not appear > > in front of the Help Desk, but should be visible to operators on demand. > > - How to "tag" 1-1 alarms individually, but even from a template, to > > which group the given alarm belongs. For example: Linux server CPU > > load Linux group, B linux server CPU load DBA group, etc.… > > > > Many thanks for your help. > > > What are your actual questions? That just looks to be a set of > requirements. Have you actually tried out Prometheus? > > -- > Stuart Clark > > -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/a0f7b607-84db-4f38-aa1a-1ccb076c709dn%40googlegroups.com.
