Hi,
I'm developing C plugin for Centos which will be installed as kernel
module. The problem is how to collect the data about:
CPU
Check ? Utilization, Model, Number of Cores
RAM
Check ? Total Memory, Free Memory, Memory Load
HDD
Check ? Number of physical HDDs, Number of logical partitions,
Total space, Free space
Running
processes ? Total number of processes
Logs
? system logs such as error logs
System
uptime
Users
logged in and last login ? total list of users
Total
network connections
Check
hardware parts model and number The kernel module will check the status of
the OS every 5 minutes. What is the most efficient way to collect these data?
Regards
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.centos.org/pipermail/centos/attachments/20101224/1e7e9089/attachment-0001.html>
On Fri, 24 Dec 2010, derleader __ wrote:> To: centos at centos.org > From: derleader __ <derleader at abv.bg> > Subject: [CentOS] Collecting data > > > Hi, > > > > > I'm developing C plugin for Centos which will be installed as kernel module. The problem is how to collect the data about: > CPU > Check ? Utilization, Model, Number of Cores > RAM > Check ? Total Memory, Free Memory, Memory Load > HDD > Check ? Number of physical HDDs, Number of logical partitions, > Total space, Free space > Running > processes ? Total number of processes > Logs > ? system logs such as error logs > System > uptime > Users > logged in and last login ? total list of users > Total > network connections > Check > hardware parts model and number The kernel module will check the status of the OS every 5 minutes. What is the most efficient way to collect these data?Check this out. It compiles the sort of thing you're doing into a loadable dynamic kernel module, that loads without having to do a reboot. Name : systemtap Arch : i386 Version : 1.1 Release : 3.el5_5.3 Size : 6.3 M Repo : installed Summary : Instrumentation System URL : http://sourceware.org/systemtap/ License : GPLv2+ Description: SystemTap is an instrumentation system for systems running Linux 2.6. : Developers can write instrumentation to collect data on the operation : of the system. Kind Regards, Keith Roberts -- In theory, theory and practice are the same; in practice they are not. This email was sent from my laptop with Centos 5.5
On 12/24/10 7:01 AM, derleader __ wrote:> Hi, > I'm developing C plugin for Centos which will be installed as > kernel module. The problem is how to collect the data about: > > * > > CPU Check ? Utilization, Model, Number of Cores > > * > > RAM Check ? Total Memory, Free Memory, Memory Load > > * > > HDD Check ? Number of physical HDDs, Number of logical > partitions, Total space, Free space > > * > > Running processes ? Total number of processes > > * > > Logs ? system logs such as error logs > > * > > System uptime > > * > > Users logged in and last login ? total list of users > > * > > Total network connections > > * > > Check hardware parts model and number > >none of that stuff should be in a kernel module. a simple daemon is far more appropriate. you can get the CPU info out of /proc/cpuinfo you can get the ram info out of /proc/meminfo you can get the HDD info from /bin/df you can get the process info from /bin/ps the logs are all in regular files as /var/log/*** the user login info can be found by parsing /var/log/wtmp the network connections via /bin/netstat -an the hardware info from lspci or lshw thats a lot of redundant and voluminuous information to be fetching every 5 minutes,
>> > Hi,>> > I'm developing C plugin for Centos which will be installed as >> > kernel module. The problem is how to collect the data about: > none of that stuff should be in a kernel module. a simple daemon is far > more appropriate. What is the most appropriate way to do this task? What are the benefits of the kernel module and daemon? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20101225/795a3770/attachment-0001.html>
On 12/24/10 4:45 PM, derleader __ wrote:> > >> > Hi, > >> > I'm developing C plugin for Centos which will be installed as > >> > kernel module. The problem is how to collect the data about: > > > > none of that stuff should be in a kernel module. a simple daemon is far > > more appropriate. > > What is the most appropriate way to do this task?What do you plan to do with the data? On the local host most is already available through the /proc interface (things that look like files to user programs) and tools already exist to read and display the values. If you want to collect data from remote hosts, snmp is the appropriate protocol and again, tools already exist.> What are the benefits of the kernel module and daemon?Normally kernel modules would only be used to communicate with specific hardware (and errors introduce the risk of crashing). Everything you mention is already available without kernel changes, although some might be reported in less than optimal ways. -- Les Mikesell lesmikesell at gmail.com
On 12/24/10 2:45 PM, derleader __ wrote:> > >> > Hi, > >> > I'm developing C plugin for Centos which will be installed as > >> > kernel module. The problem is how to collect the data about: > > > > none of that stuff should be in a kernel module. a simple daemon is far > > more appropriate. > > What is the most appropriate way to do this task?see my prior response. A daemon is simply a usermode process thats started when the system boots and runs as a dedicated service. In CentOS, these are normally started via init.d scripts and the Sys V init subsystem. but as others have pointed out there are numerous implementations of this already. Also, in addition to the programmatic data sources I mentioned, much of the more realtime sort of data (cpu load, network traffic, etc) is available via SNMP which can be queried over a network from a data collection server, once its configured. I wouldn't query the more 'inventory' sorts of data more than once a day, the number of CPUs and the hardware doesn't change very often, recording this every 5 minutes would be excessive.> What are the benefits of the kernel module and daemon?I know of no benefits of using a kernel module to perform what is readily doable in usermode. kernel modules should be reserved for things like device drivers, low level network components, file systems, and so forth. If a kernel module faults, it brings down the whole system catastrophically. a usermode daemon process would just terminate, and everything else would continue running. A daemon can run as whatever security context is appropriate for it to do its job. Most of what you described doesn't even need root privileges, but some may (lshw I believe won't be able to collect as much info if its not run as root)