Does anyone know the asadmin command line equivalent to display the Resource data as shown in the image below (ie the Resource __TimerPool)?
I'm using Payara 4.1.1.171.1.
I typed asadmin monitor --help and it provided this as
monitor [--help]
--type type
[--filename filename]
[--interval interval]
[--filter filter]
instance-name
The type field only accepts "httplistener", "jvm" and "webmodule" as inputs.
So I can't use a "resource" or "jdbcpool" as a type.
Oddly enough in the old glassfish 2.1 https://docs.oracle.com/cd/E19879-01/821-0185/gelol/index.html you can select "jdbcpool" as the type
Any help is appreciated.
I couldn't really find the answer on the payara documentation https://docs.payara.fish/documentation/payara-server/monitoring-service/monitoring-service.html
But using part of the glassfish documentation https://docs.oracle.com/cd/E18930_01/html/821-2416/ghmct.html#gipzv I was able to get what I needed.
The command is asadmin get --monitor server.resources.__TimerPool.*
This then returns (this is a partial output):
server.resources.__TimerPool.numconnused-highwatermark = 2
server.resources.__TimerPool.numconnused-lastsampletime =
1559826720029 server.resources.__TimerPool.numconnused-lowwatermark =
0 server.resources.__TimerPool.numconnused-name = NumConnUsed
server.resources.__TimerPool.numconnused-starttime = 1559823838730
server.resources.__TimerPool.numconnused-unit = count
server.resources.__TimerPool.numpotentialconnleak-count = 0
server.resources.__TimerPool.numpotentialconnleak-description = Number
of potential connection leaks
server.resources.__TimerPool.numpotentialconnleak-lastsampletime = -1
server.resources.__TimerPool.numpotentialconnleak-name =
NumPotentialConnLeak
server.resources.__TimerPool.numpotentialconnleak-starttime =
1559823838735 server.resources.__TimerPool.numpotentialconnleak-unit =
count server.resources.__TimerPool.waitqueuelength-count = 0
server.resources.__TimerPool.waitqueuelength-description = Number of
connection requests in the queue waiting to be serviced.
server.resources.__TimerPool.waitqueuelength-lastsampletime = -1
server.resources.__TimerPool.waitqueuelength-name = WaitQueueLength
server.resources.__TimerPool.waitqueuelength-starttime = 1559823838735
server.resources.__TimerPool.waitqueuelength-unit = count
Command get executed successfully.
It's important to add the .* at the end of the asadmin command in asadmin get --monitor server.resources.__TimerPool.*
If you neglect that and just enter asadmin get --monitor server.resources.__TimerPool it'll return
No monitoring data to report.
Command get executed successfully.
To see thelist of resources you have available to you to monitor type /asadmin list --monitor server.resources.*
Related
I have deployed a Splunk stand-alone server(also act as a deployment server) with docker and installed a forwarder on my PC, the forwarder management shows that the forwarder has connected to Splunk server. Then I tried to modify input.conf as below on Splunk server
[monitor://D:\git_web_test1\logs]
disabled=false
index=applogs
sourcetype=applogs
whitelist=*
I run splunk reload deploy-server then I can see the logs has pushed to the Splunk server,
however, I found it was pushed to the wrong index(main) and unexpected source type:
22/07/22 13:42:40.091
[2022-07-22T21:42:40.091] [INFO] default - server start at 8080.
host = DESKTOP-**** = D:\git_web_test1\logs\appsourcetype = app-too_small
I have never created this sourcetype before, do you know why this will happend?
The "-too_small" suffix is added to a sourcetype name when the sourcetype is undefined and the source does not contain enough data for Splunk to guess about the sourcetype's settings. A sourcetype is undefined if there is no props.conf entry for it on the indexer(s).
The fix is to create a sourcetype stanza in $SPLUNK_HOME/etc/system/local/props.conf on the Splunk server. It should look something like this:
[applogs]
TIME_PREFIX = ^
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N
MAX_TIMESTAMP_LOOKAHEAD = 23
LINE_BREAKER = ([\r\n]+)
SHOULD_LINEMERGE = false
TRUNCATE = 10000
EVENT_BREAKER_ENABLE = true
EVENT_BREAKER = ([\r\n]+)
The most likely reason why the logs are in the wrong index is the specified index doesn't exist. It's not enough to put index=applogs in inputs.conf. The same index name must be present in indexes.conf on the indexer(s). On a standalone server the index can be created in the UI at Settings->Indexes.
When using IBM PCF Messages to monitor a queue, getting values of Input Count (MQIA_OPEN_INPUT_COUNT), it works perfectly for MQ Servers installed in Windows environment, but not for Linux. Not sure if it is a code or environment issue.
If we connect to a Windows service and perform que query there are more parameters in the response if compared to the Linux.
Same code, different results. Not sure if it is a configuration on the Channel, permissions or any other environment issue. On both MQ Servers the queues are local.
I've tried using IBM.WMQ.MQC.MQCMD_INQUIRE_Q_STATUS, with no success. Didn't find any workaround to get MQIA_OPEN_INPUT_COUNT.
PCFMessages documentation is very limited, so I didn't find anything related to this problem at MQIA_OPEN_INPUT_COUNT documentation:
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q087810_.htm
Any idea of how to solve this?
Public Function GetQtyQConnections(ByVal MQQueueName As String) As Integer
Dim queueManager As IBM.WMQ.MQQueueManager = Nothing
queueManager = New IBM.WMQ.MQQueueManager(AppSettings("MQQueueManagerName"), AppSettings("MQChannelName"), AppSettings("MQConnectionName"))
Dim oPCFMessageAgent As IBM.WMQ.PCF.PCFMessageAgent = New IBM.WMQ.PCF.PCFMessageAgent
oPCFMessageAgent.Connect(queueManager)
Dim pcfMsg As IBM.WMQ.PCF.PCFMessage = New IBM.WMQ.PCF.PCFMessage(IBM.WMQ.MQC.MQCMD_INQUIRE_Q)
pcfMsg.AddParameter(IBM.WMQ.MQC.MQCA_Q_NAME, MQQueueName)
Dim pcfResponse() As IBM.WMQ.PCF.PCFMessage = oPCFMessageAgent.Send(pcfMsg)
Dim pcfResponseLen As Integer = pcfResponse.Length
Dim inputcount As Integer = -1
For i As Integer = 0 To pcfResponseLen - 1
Dim oParams() As IBM.WMQ.PCF.PCFParameter = pcfResponse(i).GetParameters
For Each oParam As IBM.WMQ.PCF.PCFParameter In oParams
Select Case oParam.Parameter
Case IBM.WMQ.MQC.MQIA_OPEN_INPUT_COUNT
inputcount = Integer.Parse(oParam.GetValue())
End Select
Next
Next
Return inputcount
End Function
On Windows:
---------------
2016-QUEUENAME
20-1
134--3
2027-2018-03-12
2028-13.59.40
2019-
22-0
2030-
2029-
2124-
96-0
95-0
98--3
2004-2018-03-12
2005-13.59.40
3-0
2119-
61-0
6-0
5-1
184-1
188-0
4-2
7-1
2013-
34-0
9-0
8-1
272-2
2008-
17-0
15-5000
13-104857600
123--3
16-0
24-0
78-0
18-0
2012-
10-0
190-0
40-80
41-20
43-0
44-0
42-1
46-0
54-999999999
21-999999999
45-1
23-1
128--3
2023-
29-1
26-0
28-1
12-0
On Linux:
---------------
2016-QUEUENAME
20-6
2027-2019-03-11
2028-17.38.24
2030-
2029-
96-0
95-0
2119-
61-1
6-0
5-1
184-1
2013-QUEUEDESCRIPTION
10-0
2017-QUEUEMANAGER
2018-QUEUENAME
45-1
2024-QUEUEMANAGER
From your output I can see that the queue you have looked at on Windows is a local queue. The second parameter you display (20) is MQIA_Q_TYPE and it has a value of (1) MQQT_LOCAL.
The queue you have looked at on Linux however is a remote queue. It's MQIA_Q_TYPE (20) parameter has a value of (6) MQQT_REMOTE.
There are many differences between local queues and remote queues, and their attributes are quite different. Try using runmqsc and display a few local and remote queues to understand the differences. These differences have not occurred because of the different platform, just because of the different queue type.
You say in your question that on both MQ Servers the queues are local, but I'm afraid that is not what your output is showing.
Also, if you want to use the Inquire Queue command, please be sure you know that OpenInputCount and OpenOutputCount are only shown for local queues, not remote queues.
If your Linux and Windows releases of IBM MQ are at the same version level then you should get the same response parameters returned.
Why don't you format your output so that it is readable to the average human? Nobody will know what you mean by 2016, 2028, etc. (except for me and a few others)
Issues:
You did not specify the "Status Type" for the request. i.e. QUEUE vs HANDLE
You did not specify any attributes for the request.
Have a look at MQListQueueStatus01.java code I posted here: IBM MQ fetch LGETTIME using Java
Finally, why don't you use C# rather than VB? You could simply use all of the Java/MQ/PCF code that I post since C# is a clone of Java (so to speak).
I wish to mimic the ldapsearch -z flag behavior of retrieving only a specific amount of entries from LDAP using python-ldap.
However, it keeps failing with the exception SIZELIMIT_EXCEEDED.
There are multiple links where the problem is reported, but the suggested solution doesn't seem to work
Python-ldap search: Size Limit Exceeded
LDAP: ldap.SIZELIMIT_EXCEEDED
I am using search_ext_s() with sizelimit parameter set to 1, which I am sure is not more than the server limit
On Wireshark, I see that 1 entry is returned and the server raises SIZELIMIT_EXCEEDED. This is the same as ldapsearch -z behavior
But the following line raises an exception and I don't know how to retrieve the returned entry
conn.search_ext_s(<base>,ldap.SCOPE_SUBTREE,'(cn=demo_user*)',['dn'],sizelimit=1)
Based upon the discussion in the comments, this is how I achieved it:
import ldap
# These are not mandatory, I just have a habit
# of setting against Microsoft Active Directory
ldap.set_option(ldap.OPT_REFERRALS, 0)
ldap.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
conn = ldap.initialize('ldap://<SERVER-IP>')
conn.simple_bind(<username>, <password>)
# Using async search version
ldap_result_id = conn.search_ext(<base-dn>, ldap.SCOPE_SUBTREE,
<filter>, [desired-attrs],
sizelimit=<your-desired-sizelimit>)
result_set = []
try:
while 1:
result_type, result_data = conn.result(ldap_result_id, 0)
if (result_data == []):
break
else:
# Handle the singular entry anyway you wish.
# I am appending here
if result_type == ldap.RES_SEARCH_ENTRY:
result_set.append(result_data)
except ldap.SIZELIMIT_EXCEEDED:
print 'Hitting sizelimit'
print result_set
Sample Output:
# My server has about 500 entries for 'demo_user' - 1,2,3 etc.
# My filter is '(cn=demo_user*)', attrs = ['cn'] with sizelimit of 5
$ python ldap_sizelimit.py
Hitting sizelimit
[[('CN=demo_user0,OU=DemoUsers,DC=ad,DC=local', {'cn': ['demo_user0']})],
[('CN=demo_user1,OU=DemoUsers,DC=ad,DC=local', {'cn': ['demo_user1']})],
[('CN=demo_user10,OU=DemoUsers,DC=ad,DC=local', {'cn': ['demo_user10']})],
[('CN=demo_user100,OU=DemoUsers,DC=ad,DC=local', {'cn': ['demo_user100']})],
[('CN=demo_user101,OU=DemoUsers,DC=ad,DC=local', {'cn': ['demo_user101']})]]
You may use play around with more srv controls to sort these etc. but I think the basic idea is conveyed ;)
You have to use the async search method LDAPObject.search_ext() and separate collect the results with LDAPObject.result() until the exception ldap.SIZELIMIT_EXCEEDED is raised.
The accepted answer works if you are searching for less users than specified by the server's sizelimit, but will fail if you wish to gather more than that (the default for AD is 1000 users).
Here's a Python3 implementation that I came up with after heavily editing what I found here and in the official documentation. At the time of writing this it works with the pip3 package python-ldap version 3.2.0.
def get_list_of_ldap_users():
hostname = "google.com"
username = "username_here"
password = "password_here"
base = "dc=google,dc=com"
print(f"Connecting to the LDAP server at '{hostname}'...")
connect = ldap.initialize(f"ldap://{hostname}")
connect.set_option(ldap.OPT_REFERRALS, 0)
connect.simple_bind_s(username, password)
connect=ldap_server
search_flt = "(cn=demo_user*)" # get all users with a specific cn
page_size = 1 # how many users to search for in each page, this depends on the server maximum setting (default is 1000)
searchreq_attrlist=["cn", "sn", "name", "userPrincipalName"] # change these to the attributes you care about
req_ctrl = SimplePagedResultsControl(criticality=True, size=page_size, cookie='')
msgid = connect.search_ext_s(base=base, scope=ldap.SCOPE_SUBTREE, filterstr=search_flt, attrlist=searchreq_attrlist, serverctrls=[req_ctrl])
total_results = []
pages = 0
while True: # loop over all of the pages using the same cookie, otherwise the search will fail
pages += 1
rtype, rdata, rmsgid, serverctrls = connect.result3(msgid)
for user in rdata:
total_results.append(user)
pctrls = [c for c in serverctrls if c.controlType == SimplePagedResultsControl.controlType]
if pctrls:
if pctrls[0].cookie: # Copy cookie from response control to request control
req_ctrl.cookie = pctrls[0].cookie
msgid = connect.search_ext_s(base=base, scope=ldap.SCOPE_SUBTREE, filterstr=search_flt, attrlist=searchreq_attrlist, serverctrls=[req_ctrl])
else:
break
else:
break
return total_results
I m working on script which will let me know running status (running/stopped) of desired application on remote desktop (windows server)
my code is doing fine until I have logged in on remote desktop (using "Remote Desktop Connection").. if I close it without logging off.. it continue work fine.. but as I log off from there .. it just stop working .. here one thing I note.. even after logging off when I run command on ssh client... it gives some successful acknowledgement
I do get desired output when remote desktop connection for that server is on from any other computer in network
ALL FOWWLOWING CODE AND OUTPUT IS WHEN I LOG OFF FROM REMOTE DESKTOP CONNECTION
string runCommand = "wmic process call create "TestClient.exe";
SshCommand command = ssh.RunCommand(runCommand);
string myData = command.Result;
after this myData will have
Executing (Win32_Process)->Create()
Method execution successful.
Out Parameters:
instance of __PARAMETERS
{
ProcessId = [some pid in numeric]; //when I be logged off, this field would not be there.. (case of problem)
ReturnValue = [some numeric];
};
but after doing this when I check status of test client by following code..
string rumCommand = "wmic process where "TestClient.exe" get ProcessID, ExecutablePath";
SshCommand command = ssh.RunCommand(rumCommand);
string myData = command.Result;
but there will not any running app listed in myData !!!
Connecting ssh client as per follow..
string pass = "password";
PasswordAuthenticationMethod PasswordConnection = new PasswordAuthenticationMethod("user_name", pass);
KeyboardInteractiveAuthenticationMethod KeyboardInteractive = new KeyboardInteractiveAuthenticationMethod("user_name");
ConnectionInfo connectionInfo = new ConnectionInfo(serverIP, port, "user_name", PasswordConnection, KeyboardInteractive);
SshClient ssh = new SshClient(connectionInfo);
if (!ssh.IsConnected)
ssh.Connect();
yeh, It was very simple problem to solve, but was in corner as well. As I had made test client (which I was testing whether they r running or not) running through task scheduler and forgot to tick on checkbox which suggest that it will be running even after Logoff.. checking this checkbox.. All Fine
I'm trying to use the asadmin interface to monitor a thread-pool on GlassFish 3.1.1. I'm executing the following command:
asadmin get -m server.network.my-listener.thread-pool.*
and I'm getting data back, but most of it has lastsampletime = -1 (so the related data is zero; and is worthless).
Note: I've also tried the REST interface, which I believe asadmin delegates to, and the JMX interface. Same problem: much of the data has lastsampletime = -1.
I've already turned monitoring to HIGH for all modules. What am I missing?
It seems like redeploying my application was necessary for the monitoring to actually get values. Perhaps I interpreted the manual incorrectly but it seems to suggest that a restart/redeploy wouldn't be required:
Oracle GlassFish Server 3.1 Administration Guide
Also, it is weird that the following shows there is no monitoring data:
asadmin get -m server.thread-pools.thread-pool.http-thread-pool.*
Instead you must go through a specific network listener like:
asadmin get -m server.network.http-listener-2.thread-pool.*
It also took me by surprise that enabling thread-pool monitoring IS NOT enough to see thread pool statistics. You must also enable http-service monitoring:
asadmin enable-monitoring
asadmin set server.monitoring-service.module-monitoring-levels.thread-pool=HIGH
asadmin set server.monitoring-service.module-monitoring-levels.http-service=HIGH
That's all you should need to do.
Enable monitoring, set to HIGH, for the http-service module on the DAS, stand-alone instance, or cluster you want to monitor.
Deploy an app to the DAS, stand-alone instance, or cluster and make http-requests.
asadmin get -m *instancename*.network.*listener*.thread-pool.*
Looks like you are monitoring DAS, since you are using asadmin get -m server.network.my-listener.thread-pool.*.
I deployed a simple war to DAS and made a bunch of http requests. I see the corethreads-count and maxthreads-count have last sample time as -1. And the remaining statistics have actual last sample times.
asadmin get -m "server.network.http-listener-1.thread-pool.*"
server.network.http-listener-1.thread-pool.corethreads-count = 0
server.network.http-listener-1.thread-pool.corethreads-description = Core number of threads in the thread pool
server.network.http-listener-1.thread-pool.corethreads-lastsampletime = -1
server.network.http-listener-1.thread-pool.corethreads-name = CoreThreads
server.network.http-listener-1.thread-pool.corethreads-starttime = 1320764890444
server.network.http-listener-1.thread-pool.corethreads-unit = count
server.network.http-listener-1.thread-pool.currentthreadcount-count = 5
server.network.http-listener-1.thread-pool.currentthreadcount-description = Provides the number of request processing threads currently in the listener thread pool
server.network.http-listener-1.thread-pool.currentthreadcount-lastsampletime = 1320765351708
server.network.http-listener-1.thread-pool.currentthreadcount-name = CurrentThreadCount
server.network.http-listener-1.thread-pool.currentthreadcount-starttime = 1320764890445
server.network.http-listener-1.thread-pool.currentthreadcount-unit = count
server.network.http-listener-1.thread-pool.currentthreadsbusy-count = 0
server.network.http-listener-1.thread-pool.currentthreadsbusy-description = Provides the number of request processing threads currently in use in the listener thread pool serving requests
server.network.http-listener-1.thread-pool.currentthreadsbusy-lastsampletime = 1320765772814
server.network.http-listener-1.thread-pool.currentthreadsbusy-name = CurrentThreadsBusy
server.network.http-listener-1.thread-pool.currentthreadsbusy-starttime = 1320764890445
server.network.http-listener-1.thread-pool.currentthreadsbusy-unit = count
server.network.http-listener-1.thread-pool.dotted-name = server.network.http-listener-1.thread-pool
server.network.http-listener-1.thread-pool.maxthreads-count = 0
server.network.http-listener-1.thread-pool.maxthreads-description = Maximum number of threads allowed in the thread pool
server.network.http-listener-1.thread-pool.maxthreads-lastsampletime = -1
server.network.http-listener-1.thread-pool.maxthreads-name = MaxThreads
server.network.http-listener-1.thread-pool.maxthreads-starttime = 1320764890443
server.network.http-listener-1.thread-pool.maxthreads-unit = count
server.network.http-listener-1.thread-pool.totalexecutedtasks-count = 31
server.network.http-listener-1.thread-pool.totalexecutedtasks-description = Provides the total number of tasks, which were executed by the thread pool
server.network.http-listener-1.thread-pool.totalexecutedtasks-lastsampletime = 1320765772814
server.network.http-listener-1.thread-pool.totalexecutedtasks-name = TotalExecutedTasksCount
server.network.http-listener-1.thread-pool.totalexecutedtasks-starttime = 1320764890444
server.network.http-listener-1.thread-pool.totalexecutedtasks-unit = count
Command get executed successfully.
To instantly enable monitoring without restart use enable-monitoring command
enable-monitoring
enable-monitoring --modules jvm=LOW
enable-monitoring --modules thread-pool=HIGH
enable-monitoring --modules http-service=HIGH
enable-monitoring --modules jdbc-connection-pool=HIGH
The trick is that thread-pool and http-service modules must have high level to get monitoring info.
For more info refer https://docs.oracle.com/cd/E26576_01/doc.312/e24928/monitoring.htm#GSADG00558