Quoting Dave Shield <[EMAIL PROTECTED]>:
> On Thu, 2005-10-13 at 12:17 +0200, Turbo Fredriksson wrote:
>> > Basic rule - all objects in a given table must use
>> > exactly the same indexing structure. If the indexing
>> > is different, that means a different table.
>>
>> Is there any way I can modify the index in such a way
>> that only need one table?
>
> By only having one job on each system :-)
>
> But seriously - no.
> If you need to report information about one or more "foo"
> things, each of which can have one or more "bar" things,
> then you need two tables:
>
> fooTable [indexed by fooIndex]
> and barTable [indexes by fooIndex, barIndex]
That was what I was trying to do...
> I just to check a few details.
> Are the statistics associated with a particular system,
> or an individual job? (Or both?) And is the list of
> statistics fixed, or variable?
Ehm... Each job _ID_ (where the statistic counters is 'linked'
to) is associated with a job _NAME_ which in turn is associated
with a client.
So for each client ('unlimited' number of clients), there's
'unilimited' (dynamically named) number of jobs with 'unlimited'
(dynamically named) number of job statistics...
So I guess one can say that the statistics is associated with
a job _ID_...
And the're static. Once a job is done, it's done. The values
won't change. Only the NUMBER of jobs change (naturally :).
Clients and Jobs is only changed if one change the configuration
but the Job _ID_ is updated at runtime. That is the actuall
job being/been executed and holds the statistics for what's done
(or WILL be done if the job is scheduled to run 'soon').
So in theory, it is possible that the statistics is empty (all
of them, but the job ID exists) in one query, but filled in another so maybe
one can't say that the're static either...
>> In LDAP (which I now know better than SQL),
>> I would have written the whole thing as:
>> ----- s n i p -----
>> +- client1
>> +- Client1_System
>> +- Client1_System.2005-09-13_01.05.06
>> +- [start date]
>> +- [end date]
>> +- [duration]
>> +- [files]
>> +- [bytes]
>> +- Client1_System.2005-09-14_01.05.06
>> +- [start date]
>> +- [end date]
>> +- [duration]
>> +- [files]
>> +- [bytes]
>> [etc, etc for each client, each job name and each job ID]
>
> So for each client you have the same five statistics - yes?
Eh, no. For each job _ID_. The 'System' here is only _my_
name of a specific job group...
Here the 'Client1_System' is the _job name_ and
'Client1_System.2005-09-14_01.05.06'
is the _job ID_...
Let's write it like this (abbreviating the stats types):
+- client1
| +- client1_job1
| | +- client1_job1_id1
| | | +- [five stats]
| | |
| | +- client1_job1_id2
| | | +- [five stats]
| | |
| | +- client1_job1_id3
| | +- [five stats]
| |
| +- client1_job2
| | +- client1_job2_id1
| | | +- [five stats]
| | |
| | +- client1_job2_id2
| | | +- [five stats]
| | |
| | +- client1_job2_id3
| | +- [five stats]
| |
| +- client1_job3
| +- client1_job3_id1
| | +- [five stats]
| |
| +- client1_job3_id2
| | +- [five stats]
| |
| +- client1_job3_id3
| +- [five stats]
|
+- client2
+- client2_job1
| +- client2_job1_id1
| | +- [five stats]
| |
| +- client2_job1_id2
| | +- [five stats]
| |
| +- client2_job1_id3
| +- [five stats]
|
+- client2_job2
| +- client2_job2_id1
| | +- [five stats]
| |
| +- client2_job2_id2
| | +- [five stats]
| |
| +- client2_job2_id3
| +- [five stats]
|
+- client2_job3
+- client2_job3_id1
| +- [five stats]
|
+- client2_job3_id2
| +- [five stats]
|
+- client2_job3_id3
+- [five stats]
> That would be represented in SNMP using a table
>
> clientSystemStatsTable
>
> with five columns (cssStartDate, cssEndDate, cssDuration,
> cssFiles, cssBytes), and indexed by the same object used
> to index the main clientSystemTable
Here the jobname is hardcoded as a table. But since I "don't
know the name of the job" (until I do an SQL query) I can't
put that into the MIB (maybe I don't have to, that's another
question).
> If these (or other) statistics are actually associated with
> a particular job, then the equivalent clientJobStatsTable
> would be indexed by a (clientSystemIndex, clientJobIndex)
> pair - exactly as for the main clientJobTable.
Oki, seems reasonable, but then we're back to the 'infinite'
number of tables (you example 'clientSystemTable' would be
'client<INIFINTE>Table' but only one job table (?)...
If I go this route, I can't put the _job name_ table in the
MIB, only the client and job ID tables... ?
Relieving my data, I came to THIS information instead
(SQL translate quite good directly to SNMP) :
ClientName JobName JobID [stats]
client1 client1_job1 client1_job1_id1 .....
client1 client1_job1 client1_job1_id2 .....
client1 client1_job1 client1_job1_id3 .....
client1 client1_job2 client1_job2_id3 .....
client1 client1_job2 client1_job2_id3 .....
client1 client1_job2 client1_job2_id3 .....
client1 client1_job3 client1_job3_id3 .....
client1 client1_job3 client1_job3_id3 .....
client1 client1_job3 client1_job3_id3 .....
client2 client2_job1 client2_job1_id3 .....
client2 client2_job1 client2_job1_id3 .....
client2 client2_job1 client2_job1_id3 .....
client2 client2_job2 client2_job2_id3 .....
client2 client2_job2 client2_job2_id3 .....
client2 client2_job2 client2_job2_id3 .....
client2 client2_job3 client2_job3_id3 .....
client2 client2_job3 client2_job3_id3 .....
client2 client2_job3 client2_job3_id3 .....
Previosly I retreived the information more like I would
if I'd do LDAP...
This, however, lead to a LOT of duplicate information.
The values for the ClientName and JobName would be more
or less the same for a whole BUNCH of lines...
In this exact example, I have the client information
eight times (per client) to much, and each job name
twice (for each client).
It would be simple though. I only need ONE table for
the whold lot! But simplicity 'is not an option' here.
I don't want all that duplicate information (if I can
avoid it)...
--
DES fissionable arrangements [Hello to all my fans in domestic
surveillance] kibo jihad spy Kennedy Saddam Hussein NSA FBI 747 Panama
FSF attack
[See http://www.aclu.org/echelonwatch/index.html for more about this]
[Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf]
If neither of these works, try http://www.aclu.org and search for echelon.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
