I'd like to use the WSADMIN command that is part of WebSphere 7 to query the state of the queues on the system.
Can anyone help me out?
Thanks
For anyone interested, here's the jython version of jeff's answer.
qpoint = 'WebSphere:*,type=SIBQueuePoint'
queues = AdminControl.queryNames(qpoint).split()
for q in queues:
identifier = AdminControl.getAttribute(q, 'identifier')
size = AdminControl.getAttribute(q, 'depth')
print identifier + ' size: ' + size + ' messages'
print AdminControl.getAttributes(q)
So to find out the queue depths I've written this JACK script...
set qpoint "WebSphere:*,type=SIBQueuePoint"
set queues [$AdminControl queryNames $qpoint]
foreach q $queues {
set identifier [$AdminControl getAttribute $q identifier]
set size [$AdminControl getAttribute $q depth]
puts "$identifier size: $size messages"
puts [$AdminControl getAttributes $q]
Stuff it in a file on the box, jeff.jacl and call the command...
/opt/IBM/WebSphere/AppServer/bin # ./wsadmin.sh -profile jp.cmd.jacl
And what do you get? well you get a whole bag of awesomeness!
WASX7209I: Connected to process "server1" on node WRSNode using SOAP connector; The type of process is: UnManagedProcess
CHANGE_REQUEST size: 15 messages
{depth 15} {state ACTIVE} {id CFAC834BE6AF5D9A30451D01_QUEUE_51} {identifier CHANGE_REQUEST} {highMessageThreshold 50000} {sendAllowed true}
ETL_DEAD size: 378 messages
Next job is to see if I can all the java code that is used by JACL directly.
In order to retrieve the depth of a SIB queue using the WebSphere PMI, you will need to select the following two counters:
AvailableMessageCount and UnavailableMessageCount
Here is how: From the WebSphere Application Server Admin Console, go to the Performance Monitoring Infrastructure (PMI) panel of the application server where the messaging engine is hosted:
Application servers > your_app_server_name > Performance Monitoring Infrastructure (PMI)
You will be on the Configuration tab by default. You can choose to switch to the Runtime tab if you wish this monitoring to start without restarting the application server.
Once on the PMI panel, click on the link "Custom", the label of the last radio button. This should take you to the Custom monitoring level panel. From the left-hand navigation tree, select:
- SIB Service
- SIB Messaging Engines - *- Destinations- Queues Select both counters: AvailableMessageCount and UnavailableMessageCount and click the Enable button located at the top. Your setting should be saved at this point.
Related
We are using 2 lb + 2 api's + 3 mysql for running our burger website. During peak order time website get slow and some time not available. We have checked the logs in detail and we could see the below in API litespeed error logs
[STDERR] [24627] Reached max children process limit: 2, extra: 0,
current: 2, busy: 2, please increase LSAPI_CHILDREN
We have tried raising the LSAPI_CHILDREN and other limits via litespeed admin url meanwhile the setting is not getting affected on back end. We get the same error again, when we have tried api cluster restart the settings are again reverted to the same.
I am attaching the screen shot of the changes we have done, the above error log is continuously logged after the change and litespeed restart. Due to continuous down issues we are moving to nginx for now. We need a proper solution for this so that we can use litespeed again.
You may use (add & set) the variable LSWS_MAX_CHILDREN in the LSWS layer (in your case) or in LLSMP layer (in case when LLSMP layer is used) to set the maximum children process limit for the server via the Dashboard.
The variables list access
Add and set the variable
Restart is required to apply changes.
To ensure the best operability, Jelastic sets this value equal to the number of available CPU cores (by default) and due to it this variable is not visible in the variable list. For more details, please follow the link LiteSpeed Web Server.
To read more about environment variables configuration, the below-listed links could be also in use:
Variables
Container Configuration
We have been facing an issue where message rate of a xmitq is very slow comparing with what should be a normal performance.
We have many other Qmgrs with bigger MQ flows that don't have the same issue.
Our HUB qmgr connects to business line in the same company HUB qmgr, and even the destination queues on their side being empty the flow is really slow.
At OS and Network level they say nothing can be done. At MQ we have changed the Buffersizes so it matches the OS level and uses the system tcp windows.
Now at MQ level we have the channel SDR setup with BATCHSZ to 100, but seems the receiver is configured with 30.
We noticed that because we see messages flow in batches fof 30 messages. Also not sure if that is related but we see the XMITQ havs always 30 uncommited messages.
Our questiong for advice.
Would increase the BATCHSZ parameter on SDR/RCVR help the perfomance?
Is there any other parameter at MQ level that could help it?
DIS CHS(NAME) ALL
AMQ8417: Display Channel Status details.
CHANNEL(QMGRA.QMGRB.T7) CHLTYPE(SDR)
BATCHES(234) BATCHSZ(30)
BUFSRCVD(235) BUFSSENT(6391)
BYTSRCVD(6996) BYTSSENT(14396692)
CHSTADA(2020-04-16) CHSTATI(14.38.17)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(159.50.69.38(48702)) CURLUWID(398F3E5EEA43381C)
CURMSGS(30) CURRENT
CURSEQNO(43488865) EXITTIME(0,0)
HBINT(300) INDOUBT(YES)
JOBNAME(000051FC00000001) LOCLADDR(10.185.8.122(54908))
LONGRTS(999999999) LSTLUWID(398F3E5EE943381C)
LSTMSGDA(2020-04-16) LSTMSGTI(14.49.46)
LSTSEQNO(43488835) MCASTAT(RUNNING)
MONCHL(HIGH) MSGS(6386)
NETTIME(2789746,3087573) NPMSPEED(NORMAL)
RQMNAME(QMGRB) SHORTRTS(10)
SSLCERTI(*******************)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(*******************)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(RECEIVE)
XBATCHSZ(23,7) XMITQ(QMGRB.X7)
XQTIME(215757414,214033427) RVERSION(08000008)
RPRODUCT(MQMM)
qm.ini:
Log:
LogPrimaryFiles=10
LogSecondaryFiles=10
LogFilePages=16384
LogType=LINEAR
LogBufferPages=4096
LogPath=/apps/wmq/QMGR/log/QMGR/
LogWriteIntegrity=SingleWrite
Service:
Name=AuthorizationService
EntryPoints=13
TCP:
SvrSndBuffSize=0
SvrRcvBuffSize=0
ServiceComponent:
Service=AuthorizationService
Name=MQSeries.UNIX.auth.service
Module=/opt/mqm75/lib64/amqzfu
ComponentDataSize=0
Channels:
MaxChannels=500
UPDATED: 15:41 GMT
Just to update the information, both sides are now with BATCHSZ 100 and seems slightly.
AMQ8417: Display Channel Status details.
CHANNEL(QMGRA.QMGRB.T7) CHLTYPE(SDR)
BATCHES(403) BATCHSZ(100)
BUFSRCVD(405) BUFSSENT(23525)
BYTSRCVD(11756) BYTSSENT(53751066)
CHSTADA(2020-04-17) CHSTATI(15.13.51)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(159.50.69.38(48702)) CURLUWID(6D66985E94343410)
CURMSGS(0) CURRENT
CURSEQNO(44115897) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000172A00000001) LOCLADDR(10.185.8.122(2223))
LONGRTS(999999999) LSTLUWID(6D66985E93343410)
LSTMSGDA(2020-04-17) LSTMSGTI(15.30.06)
LSTSEQNO(44115897) MCASTAT(RUNNING)
MONCHL(HIGH) MSGS(23505)
NETTIME(101563,480206) NPMSPEED(NORMAL)
RQMNAME(QMGRB) SHORTRTS(10)
SSLCERTI(*************************************)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(****************************)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(MQGET)
XBATCHSZ(1,1) XMITQ(QMGRB.X7)
XQTIME(191225,794134) RVERSION(08000008)
RPRODUCT(MQMM)
AMQ8450: Display queue status details.
QUEUE(QMGRB.X7) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(1)
LGETDATE(2020-04-17) LGETTIME(15.30.06)
LPUTDATE(2020-04-17) LPUTTIME(15.30.06)
MEDIALOG(S2488154.LOG) MONQ(LOW)
MSGAGE(0) OPPROCS(9)
QTIME(794134, 191225) UNCOM(NO)
I'll put a few observations in this answer, but based on any further feedback I may add more.
You are running a very old version of the software on the sender side, MQ 7.5 went out of support almost two years ago (April 30 2018). IBM for a cost will provide extended support for an additional three years, so maybe you fall in that group. The 7.5.0.2 maintenance release itself came out in July 11th 2013, so it is almost seven years old at this point. I would strongly suggest you move to a newer version.
Note that MQ v8.0 goes out of support April 30 2020, and IBM just announced a few days ago that MQ v9.0 goes out of support September 30 2021. When you do migrate you should go with either 9.1 which has no announced end of support (they give five years minimum so it could be 2023) or go with the next version of MQ that should be out some time this year.
You mention setting the following:
TCP:
SvrSndBuffSize=0
SvrRcvBuffSize=0
The above setting apply to the SVRCONN end of a client connection. You can see this in the MQ v7.5 Knowledge Center page WebSphere MQ>Configuring>Changing configuration information>Changing queue manager configuration information>TCP, LU62, NETBIOS, and SPX:
SvrSndBuffSize=32768|number
The size in bytes of the TCP/IP send buffer used by the server end of a client-connection
server-connection channel.
SvrRcvBuffSize=32768|number
The size in bytes of the TCP/IP receive buffer used by the server end of a client-connection
server-connection channel.
At IBM MQ v7.5.0.2 APAR IV58073 introduced the concept of setting various buffer settings to a value to 0 which means that it will allow the operating system defaults to be used. Unfortunately like many things in the Knowledge Center it does not look like IBM documented this correctly for 7.5.
You can however review the IBM MQ v8.0 Knowledge Center to get the full picture regarding these settings at the page Configuring>Changing configuration information>Changing queue manager configuration information>TCP, LU62, and NETBIOS, specifically you would want to set these two settings to have any impact on your Sender Channel:
SndBuffSize=number| 0
The size in bytes of the TCP/IP send buffer used by the sending end of
channels. This stanza value can be overridden by a stanza more
specific to the channel type, for example RcvSndBuffSize. If the
value is set as zero, the operating system defaults are used. If no
value is set, then the IBM MQ default, 32768, is used.
RcvSndBuffSize=number| 0
The size in bytes of the TCP/IP send buffer used by the sender end of
a receiver channel. If the value is set as zero, the operating system
defaults are used. If no value is set, then the IBM MQ default, 32768,
is used.
Starting at IBM MQ v8.0 any newly created queue manager will have all of the following in the qm.ini:
TCP:
SndBuffSize=0
RcvBuffSize=0
RcvSndBuffSize=0
RcvRcvBuffSize=0
ClntSndBuffSize=0
ClntRcvBuffSize=0
SvrSndBuffSize=0
SvrRcvBuffSize=0
However, any queue manager that is upgraded will not by default get those settings, meaning if those are not present they will not be added, if they are present they will remain the same. If the setting is not present then as it says above "the IBM MQ default, 32768, is used."
I had extensive discussions with IBM support on this topic and came to the conclusion that they did not see any reason to not set it to 0, they only saw benefit in doing so, but with an abundance of caution they do not change it to 0 for you.
I would recommend you add all of those to your qm.ini, but at minimum add the two I highlighted above.
These are good setting to implement but may not solve your problem if nothing changed recently on either end. If however something did change, for example a network difference, or MQ was upgraded to 8.0.0.8 on the remote side, then this setting just might solve your problem.
In the channel status output two values are interesting:
NETTIME(2789746,3087573)
XQTIME(215757414,214033427)
NETTIME means that based on recent activity it took 2.7 seconds to receive a response from the RCVR channel, over a longer period of time it took 3.1 seconds to receive a response from the RCVR channel. Can you compare this to a TCP ping from the sender channel server to the receive channel server, 2.7 seconds for a response over the network seems excessive. In the presentation Keeping MQ Channels Up and Running given at Capitalware's MQ Technical Conference v2.0.1.4, Paul Clarke who used to work for IBM states "NETTIME only measures network time, and does not include
the MQCMIT for example".
XQTIME means that based on recent activity and over a longer period of time it took ~215 seconds for a message on the XMITQ to be picked up by the SDR channel to be sent.
See below for how IBM documents these:
NETTIME
Amount of time, displayed in microseconds, to send a request to the remote end of the channel and receive a response. This time only measures the network time for such an operation. Two values are displayed:
A value based on recent activity over a short period.
A value based on activity over a longer period.
XQTIME
The time, in microseconds, that messages remained on the transmission queue before being retrieved. The time is measured from when the message is put onto the transmission queue until it is retrieved to be sent on the channel and, therefore, includes any interval caused by a delay in the putting application.
Two values are displayed:
A value based on recent activity over a short period.
A value based on activity over a longer period.
Information on the BATCHSZ channel parameter can be found in the IBM MQ v8.0 Knowledge Center page Reference>Configuration reference>Channel attributes>Channel attributes in alphabetical order>Batch size (BATCHSZ). I have quoted it and highlighted a few areas in bold.
This attribute is the maximum number of messages to be sent before a sync point is taken.
The batch size does not affect the way the channel transfers messages; messages are always transferred individually, but are committed or backed out as a batch.
To improve performance, you can set a batch size to define the maximum number of messages to be transferred between two sync points. The batch size to be used is negotiated when a channel starts, and the lower of the two channel definitions is taken. On some implementations, the batch size is calculated from the lowest of the two channel definitions and the two queue manager MAXUMSGS values. The actual size of a batch can be less; for example, a batch completes when there are no messages left on the transmission queue or the batch interval expires.
A large value for the batch size increases throughput, but recovery times are increased because there are more messages to back out and send again. The default BATCHSZ is 50, and you are advised to try that value first. You might choose a lower value for BATCHSZ if your communications are unreliable, making the need to recover more likely.
This attribute is valid for channel types of:
Sender
Server
Receiver
Requester
Cluster sender
Cluster receiver
Follow up questions:
Are the messages that are PUT to this XMITQ persistent?
Answer: Yes, in our PROD env all messages are pesistent.
Have you had a recent increase in volume going to this XMITQ?
Answer: No, we use a monitoring tools, we extracted a report that show very similar message rate during the period. The same rate over the last 2 weeks.
Do the putting applications set MQPMO_SYNCPOINT and then commit after 1 or more messages are PUT to the queue?
Answer: I will check with the application team.
A couple of things..
You have XBATCHSZ(1,1) so your recent batch size is 1 message per batch.
Total messages 23505 batches 403, so an average of 58 messages per batch. If your recent batch size is 1, then you must have had some larger (100?) batch sizes
XQTIME 191225 is number of microseconds messages were on the xmit queue before being sent. This is 0.1 second!
Nettime 101563 microseconds. This is a long time ( 0.1 seconds) 10,000 would be a good value. Compare this with a "TCP PING"
BUFSSENT 23525 is similar to number of messages - so message size is typically under 32K. Bytessent. messages gives 2286 so small messages.
Things to check
The queue at the remote end. Has it filled up? This would cause the sender queue to get more messages
The nettime seems very long. Compare this with TCP Ping. Nettime can include slow IO at the remote end - or a queue full at the remote end
XQTIME is high. This could be caused by sending applications not committing, or slow disk IO
I wrote "Why is my xmit queue filling up" in this blog
*Search for the title
have a read.
Capture these metrics over a day and see if they are typical
regards
Colin Paice
I set up an AMQP 1.0 link with just the path and a filter using the Apache Qpid Electron Go wrapper for Qpid Proton like this:
amqpConnection.Receiver(
// the path containing the consumer group
// and the partition Id
electron.Source("<EVENTHUB_PATH>"),
// the filter map contains some annotations filters
// for the Event Hub offset
electron.Filter(filterMap),
)
I followed this doc to setup the AMQP link options: https://godoc.org/qpid.apache.org/electron#LinkOption
However while running the Go app I've realised it was very slow in fetching messages, so I've added 2 more link options like this:
amqpConnection.Receiver(
electron.Source("<EVENTHUB_PATH>"),
electron.Capacity(100),
electron.Prefetch(true),
electron.Filter(filterMap),
)
but after adding the capacity and the prefetch link options I don't see any improvement in the performance.
I keep receiving approximately 10 messages every ~5 seconds from 4 parallel links (one link per partition).
I've tried to run the app with the environment variable PN_TRACE_RAW=true for the verbose output from Qpid Proton (cf. this: https://qpid.apache.org/releases/qpid-proton-0.18.0/proton/c/api/group__transport.html), but I am not sure
on what should I look for to troubleshoot this issue.
I don't think there is any issue with the Qpid settings, but anyway this is what I see on the terminal:
[0x9fd490]:0 -> #attach(18) [name="<MY_CUSTOM_NAME>",
handle=1, role=true, snd-settle-mode=0, rcv-settle-mode=0, source=#source(40) [address="<MY_CUSTOM_PATH>",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, filter={:string=#:"apache.org:selector-filter:string"
"amqp.annotation.x-opt-offset > '<MY_CUSTOM_OFFSET>'"}], target=#target(41) [address="",
durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false], initial-delivery-count=0,
max-message-size=0]
[0x9fd490]:0 -> #flow(19) [next-incoming-id=1, incoming-window=2147483647, next-outgoing-id=1,
outgoing-window=0, handle=1, delivery-count=0, link-credit=100, drain=false]
I also tried to run the Go app in a Azure VM in the same Azure Location as the Event Hub, but no improvement in the performance.
How could I fetch many messages at the same time in the same "round trip"?
I need to process thousands of messages per seconds.
You are correct that you need a prefetch window but the electron client can do a LOT better than that.
I did a quick test with the electron examples from https://github.com/apache/qpid-proton/tree/master/examples/go/electron
I get 3000 msg/sec even without prefetch, and nearly 10000 msgs/sec with.
$ ./broker -qsize 100000 &
Listening on [::]:5672
$ ./send -count 10000 /x ; time ./receive -count 10000 /x
Received all 10000 acknowledgements
Listening on 1 connections
Received 10000 messages
real 0m2.612s
user 0m1.611s
sys 0m0.510s
$ ./send -count 10000 /x ; time ./receive -count 10000 -prefetch 1000 /x
Received all 10000 acknowledgements
Listening on 1 connections
Received 10000 messages
real 0m1.053s
user 0m1.272s
sys 0m0.277s
There is clearly something funny going on - I'd like to help you get to the bottom of it.
PN_TRACE_RAW is a bit too verbose to be helpful, try PN_TRACE_FRM=1 which will give you a more readable summary.
I'm happy to continue the conversation either here or on users#qpid.apache.org if it turns into more of a support case than a question/answer.
Recently we started in production with a new application hosted in several WebSphere Aplication Server and would be nice to have them monitored/graphed with more or less the same parameters we monitor/graph our Jboss servers.
Right now I managed to monitor several points with wsadmin using jython scripts:
Java HEAP
Issue a "Test connection" to all datasources
However I'm not able to find the way to monitor JDBC Connection Pools, to check PoolSize, WaitingThreadCount, and FreePoolSize values. I can monitor them on RealTime using Tivoli Performance Viewer included in the WAS DMGR:
But I didn't find the way to get it through wsadmin (or any other way) so I can obtain the values and add to Cacti/RRD to obtain graphs like we already have with Jboss:
Does anyone managed to get this data from websphere with wsadmin or any other tools?
if you really insist on wsadmin
A number of WAS MBeans exposes stats attribute. This attribute represents runtime statistics of the component. In your case, the MBean type would be JDBCProvider and its stats object implements javax.management.j2ee.statistics.JDBCStats interface defined in JSR-77.
Having that stats attribute value at hand, you'll be able to extract all other data.
One important note: in wsadmin you'll need to use getAttribute_jmx function of AdminControl, not just getAttribute.
Advertisement mode Working with wsadmin and MBeans can be tough, especially when it comes to accessing complex attributes. You may find this process easier with WDR.
Other options
Starting wsadmin process periodically only to query one or two attributes seem add too much overhead to me. An alternative is to install some code in your WSAS that could expose those stats in easily consumable way. One such tool is Jolokia. Jolokia is a web application exposing MBeans via HTTTP, using XML or JSON formats. Having Jolokia running in your WSAS, you can simply query it periodically from any programming language and then feed your time series choice.
Obviously, WSAS has its own specifics: extra MBeanServer, security, hence you'll need extra descriptors and code. Also, by default Jolokia can't serialize JSR-77 objects, so you'll need to provide those serializers yourself. I've been using Jolokia with WSAS in the past and all of those missing parts can be found in a clone of Jolokia repo. Roland Huss (the author of Jolokia) implemented some of those (excluding EAR and WSAS descriptors) in Jolokia-Extra project.
Finally I managed to obtain the stats following these addresses https://www.ibm.com/developerworks/websphere/techjournal/1112_guillemenot/1112_guillemenot.html?ca=drs-
Basically I've created a function to get the statistics about JDBC connection pools I need:
def getStats(server,driver,datasource):
perfStr = AdminControl.queryNames( 'type=Perf,process=' + server + ',*')
if perfStr == "":
print "Sorry I can't find server " + server
sys.exit(1)
perfObj = AdminControl.makeObjectName( perfStr)
srvrStr = AdminControl.queryNames( 'type=Server,process=' + server + ',*')
srvrObj = AdminControl.makeObjectName( srvrStr)
stats = AdminControl.invoke_jmx( perfObj, 'getStatsObject', [ srvrObj, java.lang.Boolean('true')], ['javax.management.ObjectName', 'java.lang.Boolean'])
try:
waitingThreads=stats.getStats('connectionPoolModule').getStats(driver).getStats(datasource).getStatistic('WaitingThreadCount').getCurrent()
poolSize=stats.getStats('connectionPoolModule').getStats(driver).getStats(datasource).getStatistic('PoolSize').getCurrent()
freePoolSize=stats.getStats('connectionPoolModule').getStats(driver).getStats(datasource).getStatistic('FreePoolSize').getCurrent()
percentUsed=stats.getStats('connectionPoolModule').getStats(driver).getStats(datasource).getStatistic('PercentUsed').getCurrent()
print "WaitingThreadCount=" + str(waitingThreads) + ", PoolSize=" + str(poolSize) + ", FreePoolSize=" + str(freePoolSize) + ", PercentUsed=" + str(percentUsed)
except:
print "Ooops, something went wrong :("
raise
And in order to identify server, driver and datasource variables I also added a function to list them:
def listServers():
"""List the servers Database Connection Pools"""
servers = AdminControl.queryNames( 'type=Perf,*').split("\n")
for i in range(0, len(servers)):
srvName = servers[i].split(",")[1].split("=")[1]
if srvName == "nodeagent":
continue
print "Server: " + srvName
perfStr = AdminControl.queryNames( 'type=Perf,process=' + srvName +',*')
perfObj = AdminControl.makeObjectName( perfStr)
srvrStr = AdminControl.queryNames( 'type=Server,process=' + srvName +',*')
srvrObj = AdminControl.makeObjectName( srvrStr)
stats = AdminControl.invoke_jmx( perfObj, 'getStatsObject', [ srvrObj, java.lang.Boolean('true')], ['javax.management.ObjectName', 'java.lang.Boolean'])
for driver in stats.getStats('connectionPoolModule').subCollections():
print "\tDriver Name: " + driver.getName()
for datasource in stats.getStats('connectionPoolModule').getStats(driver.getName()).subCollections():
print "\t\tDatasource: " + datasource.getName()
Which will output something like:
Server: APP_CLUSTER_APP01
Driver Name: Oracle JDBC Driver (XA)
Datasource: jdbc/AppEngine
Datasource: jdbc/AppEngineH
Server: APP_CLUSTER_APP02
Driver Name: Oracle JDBC Driver (XA)
Datasource: jdbc/AppEngine
Datasource: jdbc/AppEngineH
Server: SOL_CLUSTER_SOL01
Driver Name: Oracle JDBC Driver (XA)
Datasource: jdbc/dict1ds
Datasource: jdbc/dict2ds
Datasource: jdbc/dict3ds
Server: SOL_CLUSTER_SOL02
Driver Name: Oracle JDBC Driver (XA)
Datasource: jdbc/dict1ds
Datasource: jdbc/dict2ds
Datasource: jdbc/dict3ds
In order to set up a self-monitoring of a linux OS (CentOS) in order to send traps if a condition occurs i have configured the lines
com2sec notConfigUser default Public0
group notConfigGroup v1 notConfigUser
group notConfigGroup v2c notConfigUser
view systemview included .1
access notConfigGroup "" any noauth exact systemview systemview none
for disk query
disk / 100000000
trap2sink 10.10.64.132
authorization for self monitoring
rouser admin
iquerySecName admin
define message to send OID to monitor threshold values
monitor -r 10 DiskAlmostFull dskPercent < 90
monitor -r 10 machineTooBusy hrProcessorLoad < 90
But the traps are generated only when i restart the snmpd deamon.
I have tried to troubleshoot this issue without success.
Any held will be helpful.
Thanks in advance
Having had the same problem, I discovered the following explanation in "man snmpd.conf".
Section "monitor [OPTIONS] NAME EXPRESSION" states:
"Note that the event will only be triggered once, when the expression first matches. This monitor entry will not fire again until the monitored condition first becomes false, and then matches again."
You may not like the answer, but the monitor command behaves as advertised.