Inventory servers without disgust
I want to share the story of a successful project to create a server inventory system. The story will be useful to those who want to finally restore order in their server economy and are looking for real examples with answers to questions.
This is exactly a story in the style of success story, but not installation instructions. Since step by step how to on the Internet and on this site for this product abound. But they all talk about the inventory of the PC, and the servers have their own nuances. GLPI, despite existing server functionality and plugins, specializes in PC inventory. But in skillful hands, you can sharpen it for the needs of server administrators (network, by the way, too). Perhaps the methods used by programmers will cause criticism, but I remind you that it was done by admins and for admins.
')
Probably it is not necessary to explain how important it is to have up-to-date access to up-to-date information about the ward zoo machinery. Especially it becomes important when the number begins to pass over a hundred. Surely everyone goes through the exel file with the required fields. With the same probability, everyone had a feeling of disgust from this method when hammering or modifying a dozen lines.
Having worked in one cellular operator where the number of servers was calculated in 4-digit numbers and appreciated the charms of the samopisnaya system used there for inventory, I was puzzled by the search for something similar for my new employer. Hint threw the blog Badoo on Habré.
In one article, there was a mention of using the FusionInventory + GLPI bundle to collect information on installed servers. Due to the great respect for the rest of the technologies used in the article, I decided to try this out in our environment.
A few words about the products:
Both products are Open Source, both are periodically updated and supplemented with new features. But from both products we need only part of the functionality:
After studying the functionality and understanding that it will take what is not, we cut off all unnecessary in the interface. This is perfectly handled through a flexible profile management system. Creating a profile for server administrators and carefully walking through the available checkmarks ruthlessly wiped out all unused functionality. In this form, you and your colleagues will not be distracted from the main task of this resource - painstaking information gathering.
The severe legacy of GLPI as a helpdesk tool will have to be cut by climbing into the code. My skills in PHP on which the system is written is enough for an intuitive understanding of the code, but despite this you can do quite a lot. First, I recommend correcting the localization in order for the elements of the inventory to be called not computers, but servers. It seems to be not a particularly significant point, but it helps in the correct positioning of the product within the company.
The file with Russian localization is stored by default here: /usr/share/glpi/locales/ru_RU.php. Make a backup and feel free to edit the names.
Next, I recommend changing the default page to the list of servers. This will reduce a couple of clicks access to the most relevant information and remove unnecessary questions:
Next, we define a set of fields that we want to see for the servers. In our case, this resulted in such a list:
Let's try to remove the excess from our web server display. To do this, you need to edit the computer class: /usr/share/glpi/inc/computer.class.php . We find the function showForm (and comment on the output fields.
With a successful arrangement by carrying the remaining fields, we obtain a similar form:
I advise you to create templates with predefined fields to reduce aversion from filling the inventory.
Hint 1: By adding a couple of lines to the same function, you can get a convenient link to an item in the nagios monitoring system which has a backward link to the inventory (see screenshot above):
Hint 2: Renaming the “inventory number” field not used by our team to “console address” and changing the type to url was able to switch directly to the SP console directly from the server list. Helps to quickly solve problems with a failed server.
Also, in order not to distract our administrators with unnecessary elements, I recommend commenting out these tabs in the same file (some of them can be removed by killing rights through the profile):
In order not to drive in information on the components used the plugin FusionInventory. Very good article on its installation is already on Habré . I can only add from myself what has been changed in our case.
Agents do not want to put in mind, and so a large number of outsiders on the servers. Especially most often, one run is enough to collect data. Not every day you have changed the OS or components on the server. Balls in the network (CIFS and NFS) and the FusionInventory agent distribution kit unpacked on it for each OS used in the company allows you to collect data into one command:
How to run this procedure en masse in your company is up to you. After launch, we will either receive a new object in the inventory or update the data of the existing one (uniqueness is checked by serial / MAC / IP / name) with clogged data:
In the settings of the FusionInventory plugin, disable the collection of the information that you do not need.
Hint: the result of the agent can be downloaded to a file, and then imported into GLPI. This mechanism creates an idial API for automatically loading any data. We implemented on this opportunity data import by virtual machines from our VMware farm.
The FusionInventory plugin for these tasks has its own tool, but it adds components to the server, instead of creating full-fledged server list items. What is not so convenient. In the latest version released a couple of months ago, there was a choice to create an element for virtualoks or components to an ESXi server.
Since there are a lot of admins in the team, they periodically go on vacation or are ill, you need to collect information about active requests in the TP somewhere. It is also useful to know what problems were with this server (and in our case with the settlement, switches and software).
The solution is in the GLPI - application, but in this case they imply an application outside, not inside the IT team. To simplify the application procedure, a similar functional cut was made:
Get a list of open or closed tickets:
Actually, the inventory of servers is completed on this; further, depending on the need, we add functionality to the plugins . I recommend these add-ons:
Actually that's all. If readers have an interest in add-ons and how we use them, I will write a separate article about the implementation of these plug-ins, but to understand how it looks, I’m throwing screenshots:
Custom elements - storages
IT services
Racks
This is exactly a story in the style of success story, but not installation instructions. Since step by step how to on the Internet and on this site for this product abound. But they all talk about the inventory of the PC, and the servers have their own nuances. GLPI, despite existing server functionality and plugins, specializes in PC inventory. But in skillful hands, you can sharpen it for the needs of server administrators (network, by the way, too). Perhaps the methods used by programmers will cause criticism, but I remind you that it was done by admins and for admins.
')
Prehistory
Probably it is not necessary to explain how important it is to have up-to-date access to up-to-date information about the ward zoo machinery. Especially it becomes important when the number begins to pass over a hundred. Surely everyone goes through the exel file with the required fields. With the same probability, everyone had a feeling of disgust from this method when hammering or modifying a dozen lines.
Having worked in one cellular operator where the number of servers was calculated in 4-digit numbers and appreciated the charms of the samopisnaya system used there for inventory, I was puzzled by the search for something similar for my new employer. Hint threw the blog Badoo on Habré.
In one article, there was a mention of using the FusionInventory + GLPI bundle to collect information on installed servers. Due to the great respect for the rest of the technologies used in the article, I decided to try this out in our environment.
Implementation
A few words about the products:
- GLPI - a system for organizing heldesk in an enterprise with an equipment database
- FusionInventory - automate data collection and task execution
Both products are Open Source, both are periodically updated and supplemented with new features. But from both products we need only part of the functionality:
- Storage of basic information on servers and virtual machines:
- Automatic collection of this data from servers
- Tracking requests to external technical support
- Storage of information about the TP (who provides support, at what level and when does it end)
- Association of servers with IT business services
- Tracking server location in rack
- Create reports
After studying the functionality and understanding that it will take what is not, we cut off all unnecessary in the interface. This is perfectly handled through a flexible profile management system. Creating a profile for server administrators and carefully walking through the available checkmarks ruthlessly wiped out all unused functionality. In this form, you and your colleagues will not be distracted from the main task of this resource - painstaking information gathering.
Surface tuning
The severe legacy of GLPI as a helpdesk tool will have to be cut by climbing into the code. My skills in PHP on which the system is written is enough for an intuitive understanding of the code, but despite this you can do quite a lot. First, I recommend correcting the localization in order for the elements of the inventory to be called not computers, but servers. It seems to be not a particularly significant point, but it helps in the correct positioning of the product within the company.
The file with Russian localization is stored by default here: /usr/share/glpi/locales/ru_RU.php. Make a backup and feel free to edit the names.
Next, I recommend changing the default page to the list of servers. This will reduce a couple of clicks access to the most relevant information and remove unnecessary questions:
cp /usr/share/glpi/front/central.php /usr/share/glpi/front/central.php.b cp /usr/share/glpi/front/computer.php /usr/share/glpi/front/central.php Next, we define a set of fields that we want to see for the servers. In our case, this resulted in such a list:
- Server name
- Serial number
- Model
- OS
- Management Console Address
- Status
- Location
- Contact responsible for applications on the server: person and division
Let's try to remove the excess from our web server display. To do this, you need to edit the computer class: /usr/share/glpi/inc/computer.class.php . We find the function showForm (and comment on the output fields.
With a successful arrangement by carrying the remaining fields, we obtain a similar form:
I advise you to create templates with predefined fields to reduce aversion from filling the inventory.
Hint 1: By adding a couple of lines to the same function, you can get a convenient link to an item in the nagios monitoring system which has a backward link to the inventory (see screenshot above):
echo "<tr class='tab_bg_1'>"; echo "<td></td><td></td>"; echo "<td></td>"; echo "<td><a href=http://nagios/check_mk/view.py?view_name=host&site=&host=".$this->fields["name"]."> Server monitoring in NAGIOS </a> </td>"; Hint 2: Renaming the “inventory number” field not used by our team to “console address” and changing the type to url was able to switch directly to the SP console directly from the server list. Helps to quickly solve problems with a failed server.
Also, in order not to distract our administrators with unnecessary elements, I recommend commenting out these tabs in the same file (some of them can be removed by killing rights through the profile):
# $this->addStandardTab('ComputerVirtualMachine', $ong, $options); # $this->addStandardTab('RegistryKey', $ong, $options); # $this->addStandardTab('Item_Problem', $ong, $options); # $this->addStandardTab('Link', $ong, $options); # $this->addStandardTab('Reservation', $ong, $options); # $this->addStandardTab('OcsLink', $ong, $options); # $this->addStandardTab('Computer_SoftwareVersion', $ong, $options); # $this->addStandardTab('Note', $ong, $options); # $this->addStandardTab('Document', $ong, $options); Data collection
In order not to drive in information on the components used the plugin FusionInventory. Very good article on its installation is already on Habré . I can only add from myself what has been changed in our case.
Agents do not want to put in mind, and so a large number of outsiders on the servers. Especially most often, one run is enough to collect data. Not every day you have changed the OS or components on the server. Balls in the network (CIFS and NFS) and the FusionInventory agent distribution kit unpacked on it for each OS used in the company allows you to collect data into one command:
- \\ share \ FusionInventory \ Windows \ fusioninventory-agent.bat
- / net / share / FusionInventory / RHEL / fusioninventory-agent
How to run this procedure en masse in your company is up to you. After launch, we will either receive a new object in the inventory or update the data of the existing one (uniqueness is checked by serial / MAC / IP / name) with clogged data:
In the settings of the FusionInventory plugin, disable the collection of the information that you do not need.
Hint: the result of the agent can be downloaded to a file, and then imported into GLPI. This mechanism creates an idial API for automatically loading any data. We implemented on this opportunity data import by virtual machines from our VMware farm.
The FusionInventory plugin for these tasks has its own tool, but it adds components to the server, instead of creating full-fledged server list items. What is not so convenient. In the latest version released a couple of months ago, there was a choice to create an element for virtualoks or components to an ESXi server.
We track external requests
Since there are a lot of admins in the team, they periodically go on vacation or are ill, you need to collect information about active requests in the TP somewhere. It is also useful to know what problems were with this server (and in our case with the settlement, switches and software).
The solution is in the GLPI - application, but in this case they imply an application outside, not inside the IT team. To simplify the application procedure, a similar functional cut was made:
Get a list of open or closed tickets:
Addition
Actually, the inventory of servers is completed on this; further, depending on the need, we add functionality to the plugins . I recommend these add-ons:
- Appliances - the ability to integrate servers by the service they provide
- Bays Management - management of server racks, their power supply, location of servers in the rack
- Custom Fields - add custom fields to existing elements
- Databases - Database Inventory, Association with Services and Servers
- File injection - Import elements from a csv file
- Objects management - Creating custom objects
Actually that's all. If readers have an interest in add-ons and how we use them, I will write a separate article about the implementation of these plug-ins, but to understand how it looks, I’m throwing screenshots:
Custom elements - storages
IT services
Racks
Source: https://habr.com/ru/post/200476/
All Articles