Срочно Нужен Програмист (LINUX)

Срочно Нужен Програмист (LINUX)

DTCLV

Сообщения: n/a

Specification

1. System componentns and structure

System introduces the following concepts:
- device
- protocol
- sensor
- sensor group
- report/graph
- alarm
- scheduler

Here is description of those terms and how are they used:

1.1 device

Device is router, cisco or switch with assigned IP address. (Actually it may be not even IP address but whatever protocol plugin supports)
Administration system will allow add, edit, delete, put notes and descriptions, disable or mark devices as important. It will also maintain error log of device's related protocol plugins.
New devices may be added manualy, but may be imported as well (see device importing)
Device information exists as record in database. Device is treated by system as sensor group.

1.2 protocol

For each device number of protocols will be available to use for statistics fetching like ICMP, SNMP. Protocol types are implemented as PHP classes. Protocols are identified by symbolic name such as "icmp", "snmp", "icmp-v2"
New protocols may be added as new clases or as extentions of existing protocols.
Developing protocol plugin will be documented

1.3 sensor

Each protocol provide sensors.
s://195.2.96.2/icmp/roundtrip is example of integer sensor. Another example is s://195.2.96.2/icmp/availability which is boolean sensor. SNMP's plugin sensor name is item description fetched from device.

Sensors may take arguments very similar to notation used in Web URL.
s://195.2.96.2/icmp/availability?tries=3&statisfy=1 means to send 3 icmp packets and single response will statisfy sensor and return it true.

Theoretically development of following plugin is also possible and easy:
s://195.2.96.2/average?last=30&sensor=icmp/roundtrip
which would report average from last 30 requests to roundtrip sensor which will occur every 10 minutes.

1.4 sensor group

As I already mentioned earlier - first example of sensor group is device itself. Sensor group combines number of sensors. Sensor group types are also implemented as PHP classes which gives wide feature range.

Groups are refered like this:
g://group/home-users/zolitude/pings
g:// - means, that we are referencing group of sensors, group - type of group. group stands for simple one-per-line sensor list /home-users/zolitude/pings - name of group.

which would hold sensors:
s://195.2.118.23/icmp/availability
s://195.2.118.24/icmp/availability
.. etc.

There may be more group types working with patterns, ip subnets or even other groups. The nice example of such a group would be:
g://ipmask/195.2.96.0/24

1.5 report/graph

To the system, report is a special case of sensor group. There can be number of report with one of few report types. Reports are referenced like this:
r://daily-graph/server-boxes?day=03.07.2003
which would display one-day graph for assigned sensors/groups.

Report is generated on-the-fly when requested. Server-boxes is report name which may contain another group or list of sensors. Day is parameter showing which day is to be displayed. By default, if report-name does not exist, group with same name is checked. Here is some example:
r://daily-graph/group/home-users/zolitude/pings?day=03.07.2003
which would display graph for this group.

1.6 alarm

Alarm is another special case of sensor group. Depending on alarm type checks are done to all grouped sensors. Check are depended on alarm type. Alarm example:
a://range-check/cisco-memory?min=1M

Here, cisco-memory is the name of alarm, which may contain sensors or sensor groups. Every sensor in every group is checked to be atleast 1M. If some sensors do not match criteria, their names, values and minimal reqested value is outputed.

Alarm will remember list of sensors, which generated failure checks. Once sensor triggered alarm, it will be ignored untill it goes back to accepted range, then anothe alarm will be issued.

Here is sample output of triggered alarm:
The following sensors did not past test of: minimum 1M
s://195.2.118.1/

1.7 scheduler

Since alarm group don't send anything but just output data, there should be another component to send notification and it's scheduler.
Schedulers can be set to be executed periodicaly. Scheduler also is group. You may want to setup scheduler to contain some alarms, then they will be checked eventualy and if alarm made any output (signaling about problem)
Another user of scheduler is mailing reports.

2. Using System

All the information in previous chapter may be too much to remember / understand. It will be surely much simplified by administration system and other components.

2.1 Components

- MySQL database server required information. It will not store all possible SNMP keys from devices, but only about used ones.
- Administration system in PHP. It will be available only to administrator and will allow adding devices, reports, sensors, schedulers and much more.
- Report system will allow to watch sensors, reports and groups without changing them. Access will also be restricted and placed in browser cookies. The person received allert / report will be able to click on the link or copy-paste paths into reporting system to see visual data, graphs, current values, etc.
- Cron will be running pereodic php handler, which will watch schedulers and send reports and alerts.
- Cron job to check existing sensors.
- Perl plugins may be developed and used through specificly written extention PHP classes.

2.2 Other features

All other requested features will be handled my plugins, report types and sensor types.
- web based charts are report type
- action system (script launching, email-sending, etc) is up to used scheduler type. New action type may be done easily by adding another scheduler type. Treshold exceeding, icmp availity, maximal load, minimum memory are all implemented as sensors / alarms.
- externad database is mySQL. However, if needed - export/import application will be developed.
- autodiscovery of incerfaces is performed by administration sysem or import application. You would be able to specify list of device IP addresses which will automaticaly checked for sensor existance. All new sensors may be added into groups.
- Interfaces are checked by description. Description is used as argument to snmp sensor.It's easy to change description, include sensor into group or exclude it. Statistics is saved for sensor and may be used by graphs, for example.
- Interface up, down, input, output, crc, collision, bandwidth, cpu load, memory load are implemented as sensors, perhaps with parameters.
- Time perioud can be specified to any report type or can be set system-wide.
- Report for many interfaces is the matter of including it into groups.
- Set alert theshold for each interface - this is done by adding more alarms. You can even put 2 alarms on sensor - one is more tight and informative, other is critical.

3. Summary

This data organization and structure is the most effective, flexible and easy way to manage statistics. If you have any suggestions or reasons, why this structure cannot be implemented - feel free to reply.

Отправлено: 16:16, 27-08-2003

enthusiast Сообщения: n/a	Профиль \| Цитировать А каково оплата ? и также какие льготы имеются ? Добавлено: А каково оплата ? и также какие льготы имеются ?
	Отправлено: 09:35, 29-08-2003 \| #2

Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.

Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.

DTCLV Сообщения: n/a	Профиль \| Цитировать Либо здесь, либо ничего не будет, никаких писем и т. п. (Не)Желающие - идут на job.ru сотоварищи. [s]Исправлено: vasketsov, 21:22 29-08-2003[/s]
	Отправлено: 11:18, 29-08-2003 \| #3