Changing Google Chrome Profile Images

This has hacked me off for years, such a simple request, but clearly not simple enough for Google to take the effort in getting it to work how users would like.

Let's start with the problem.  Google profiles are a great way to organise your browser, especially if like me you have your personal account and accounts that will be used for different customers.  Whilst you can give a profile a name, change the icon and customse the colour theme the list of icons that you can use is limited to a bunch of random subjects that only make sense if you're on drugs.

To change your profile image you navigate to chrome://settings/manageProfile 

Now when you scroll down to pick an avitar you will see all the available images;

This is where the hack really starts.

As you click on each avitar a file appears in "%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Avatars". After you have clicked all the icons you will end up with the following list of files, you don't need to click on all of them just as many as you want to change.

Now you can edit any of these files with paint and change the images.

There are two drawbacks with this approach.

1. The icon displayed in the windows task bar does not change, see below, the second chrome icon still has the avacado avitar, but this is a file that I have changed.

2. The icon displayed when chosing a new avitar does not change either, so you have to know which images you changed and what their corresponding names are.

However you will end up with the correct image displayed on the browser tool bar

and also when you chose a new profile

or when starting Chrome.

As always happy hacking, hopefully one day this blog will become redundat.

ZScaler and Python

I encountered an issue where my organisation removed the permissions for me to be able to disable the ZScaler client on my desktop and all my python scripts stopped wortking.

They would throw this error.

Traceback (most recent call last):
  File "./myScript.py", line 798, in <module>
    main()
  File "./myScript.py", line 788, in main
    doSomething()
  File "./myScript", line 175, in report_all_compute
    instances = oci.pagination.list_call_get_all_results(compute.list_instances,compartment_id=compartment.id)

  File "/python/.venv/lib/python3.6/site-packages/oci/pagination/pagination_utils.py", line 205, in list_call_get_all_results
    for response in list_call_get_all_results_generator(list_func_ref, 'response', *list_func_args, **list_func_kwargs):
  File "/python/.venv/lib/python3.6/site-packages/oci/pagination/pagination_utils.py", line 274, in list_call_get_all_results_generator
    call_result = retry.DEFAULT_RETRY_STRATEGY.make_retrying_call(list_func_ref, *list_func_args, **list_func_kwargs)
  File "/python/.venv/lib/python3.6/site-packages/oci/retry/retry.py", line 308, in make_retrying_call
    response = func_ref(*func_args, **func_kwargs)
  File "/python/.venv/lib/python3.6/site-packages/oci/core/compute_client.py", line 7885, in list_instances
    api_reference_link=api_reference_link)
  File "/python/.venv/lib/python3.6/site-packages/oci/base_client.py", line 477, in call_api
    response = self.request(request, allow_control_chars, operation_name, api_reference_link)
  File "/python/.venv/lib/python3.6/site-packages/oci/base_client.py", line 598, in request
    raise exceptions.RequestException(e)
oci.exceptions.RequestException: (MaxRetryError("OCIConnectionPool(host='iaas.uk-london-1.oraclecloud.com', port=443): Max retries exceeded with url: /20160918/instances?compartmentId=myCompartmentID (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:852)'),))",), 'Request Endpoint: GET https://iaas.uk-london-1.oraclecloud.com/20160918/instances See https://docs.oracle.com/en-us/iaas/Content/API/Concepts/sdk_troubleshooting.htm for help troubleshooting this error, or contact support and provide this full error message.')

The basic problem is that Python doesn't know about the ZScaler certificate chain.

If your organisation uses ZScaler any URL you visit will show a ZScaler certificate, like the one below.  Click on the padlock icon next to the URL in your browser.

Click on the Details tab and extract all three ZScaler certificates.

Now look for your python certificate strore, run pyton and ask it where it is stored.

python
Python 3.6.9 (default, Mar 15 2022, 13:55:28)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import certifi
>>> certifi.where()
'/python/.venv/lib/python3.6/site-packages/certifi/cacert.pem'

Append the new certficate PEM files to the end of this file and all will magically start working.

Happy hacking.

Reset OMC Log Analytics file collections

Developing a series of log analytics log parsers and log sources is trickey at the best of times.  Rather than using the on-demand upload I wanted the Oracle Management Cloud agent to pick up the files.

As is almost always the case I had to delete the data and try again, several times.  If you don't delete the data first you will end up with duplicate log records.

Deleting the data was easy.

First of all remove the association to the entity that the log source is tied to, then goto the Log Admin section and define a query to delete all the previously uploaded data, in my case that was:-

'Log Source'='OIC Connectivity Agent Log Source'

Unfortunately log analytics has a bunch of internal state files that keep a record of what has already been processed.

These files are contained in $AGENT_INST/sysman/emd/state/loganalytics/os_file and contain data similar to:-

version=154

dirName=/home/oracle/OICS_CONNECTIVITYAGENT02/agenthome/logs

isLargeDir=false

forwardTime=0

forwardFileName=null

backwardTime=0

backwardFileName=null

lastReadCycleTime=1631087347454

################################

agent-diagnostic7.log;80467459;1629238676000;10485951;10485951;ISO-8859-1;UTC;2021-08-14T14:12:42.991Z;0

agent-diagnostic5.log;80467469;1629814398000;10485780;10485780;ISO-8859-1;UTC;2021-08-21T06:15:54.435Z;0

agent-diagnostic6.log;80467468;1629526554000;10486076;10486076;ISO-8859-1;UTC;2021-08-17T22:17:56.123Z;0

agent-diagnostic8.log;80467467;1628950362000;10485898;10485898;ISO-8859-1;UTC;2021-08-11T05:50:17.475Z;0

agent-diagnostic3.log;80467462;1630389762000;10485783;10485783;ISO-8859-1;UTC;2021-08-27T22:07:46.938Z;0

agent-diagnostic4.log;80467470;1630102066000;10485844;10485844;ISO-8859-1;UTC;2021-08-24T14:13:18.831Z;0

agent-diagnostic9.log;80467466;1628661017000;10485860;10485860;ISO-8859-1;UTC;2021-08-09T04:44:02.439Z;0

agent-diagnostic0.log;80467465;1631087314000;5765858;5765858;ISO-8859-1;UTC;2021-09-06T21:52:22.778Z;0

agent-diagnostic1.log;80467464;1630965142000;10485953;10485953;ISO-8859-1;UTC;2021-09-03T13:57:31.951Z;0

agent-diagnostic2.log;80467463;1630677451000;10485791;10485791;ISO-8859-1;UTC;2021-08-31T06:02:42.259Z;0

agent-upgrade.log;69530634;1631011778000;552233;552233;ISO-8859-1;UTC;2021-07-31T19:49:30.218Z;0

agent-audit.log.1;69832466;1625572011000;6500;6500;ISO-8859-1;UTC;2021-01-06T14:37:06.813Z;0

agent-alert.log;69530630;1631033124000;734154;734154;ISO-8859-1;UTC;2021-08-01T17:24:50.482Z;0

agent-audit.log;69530632;1626101136000;553854;553854;ISO-8859-1;UTC;2020-08-21T11:15:12.950Z;0

Stop the OMC Agent using omcli stop agent

Delete the file associated for your log source

Start the OMC Agent using omcli start agent

Re-Associate the entity using the OMC console.

Error evaluating HT_Memory:non_windows_generic_apache_perf

You may have seen my other blog Error evaluating omc_PerformanceOverview:non_windows_generic_apache_perf, well this is an extension to it for a different metric.

The error you see in the UI is;

Error evaluating HT_Memory:non_windows_generic_apache_perf - java.lang.Throwable: PidFile location (/etc/httpd/logs/httpd.pid) is not an absolute path for the httpd.pid file. at /home/agent/omcagent/200120.2234/plugins/oracle.em.sgfm.zip/1.47.0/scripts/generic_apache/ahs_get_memoryUsage.pl line 49.

There is an optional parameter omc_pid_file_location that defaults to omc_server_root/logs/httpd.pid.  Unfortunately, you cannot set this value using the UI.

The previous sentence is no longer valid,  the OMC UI now displays the parameter in the configure entities screen.  So you can skip to "Making sure the OMC agent user can read the PID file".

The script mentioned in the alert, which even though I am on 1.48.1 references the wrong location, which doesn’t exist has this snippet;

if ( !( -f $pidFileLoc ) ) {

    die("PidFile location ($pidFileLoc) is not an absolute path for the httpd.pid file.");

}

The perl "-f" test tests if the file is a plain file.

There are two problems with this;

1. My PID is not stored in that location.
2. My Apache is running as the user "apache" and the OMC agent doesn’t have access to the file even if it existed so it would fail for that reason.

To fix the problem we need to add the omc_pid_file_location property and make the httpd.pid file readable to the OMC agent user.

To add this property to the Apache entity update it using the omcli update_entity command.

First create a JSON payload representing your Apache entity.

$ more ~/apache.json

{

    "entities": [

        {

            "name": "MyApache",

            "type": "omc_generic_apache",

            "entityDisplayName": "MyApache",

            "properties": {

                "omc_pid_file_location": {

                    "displayName": "PID file location for httpd process",

                    "value": "/etc/httpd/run/httpd.pid"

                }

            }

        }

    ]

}

Run this command to update the entity.

$ omcli update_entity agent ~/apache.json

Oracle Management Cloud Agent

Copyright (c) 1996, 2020 Oracle Corporation.  All rights reserved.

Operation Succeeded: Accepted 1 of 1 entities for processing.

Make sure that the OMC agent user can read the PID file.

$ ls -l /etc/httpd/run/httpd.pid

ls: cannot access /etc/httpd/run/httpd.pid: Permission denied

For me it turns out that the agent user cannot access /run/httpd

$ ls -ltrh /etc/httpd

total 12K

drwxr-xr-x. 2 root root 4.0K Jun 27  2019 conf.modules.d

lrwxrwxrwx. 1 root root   19 Jun 27  2019 logs -> ../../var/log/httpd

lrwxrwxrwx. 1 root root   10 Jun 27  2019 run -> /run/httpd

lrwxrwxrwx. 1 root root   29 Jun 27  2019 modules -> ../../usr/lib64/httpd/modules

drwxr-xr-x. 2 root root 4.0K Apr  3 12:50 conf

drwxr-xr-x. 2 root root 4.0K Apr 24 12:04 conf.d

$ ls -ltrh /run | grep httpd

drwx--x---.  3 root               apache              100 May  3 03:13 httpd

User setfacl to grant access.

$ sudo setfacl -m u:agentuser:x /etc/httpd/run

$ sudo setfacl -m u:agentuser:rx /etc/httpd/run/httpd.pid

You can check that everything is working fine by running;

$ omcli getMetric agent MyApache,omc_generic_apache,HT_Memory

Oracle Management Cloud Agent

Copyright (c) 1996, 2020 Oracle Corporation.  All rights reserved.

memoryUsedGB,memoryUtilizationPercent,intervalSec

0.0769462585449219,0,0

Error evaluating omc_PerformanceOverview:non_windows_generic_apache_perf

Okay so fighting with Oracle Management Cloud to try and get it to monitor a generic Apache server on Oracle Linux.

Other than Apache actually being up and serving content the next thing that you're interested in is performance.

This is the error that you might see.

 Error evaluating omc_PerformanceOverview:non_windows_generic_apache_perf - java.lang.Throwable: Please check the 'server-status' configuration in the httpd.conf file at /home/omcagent/plugins/oracle.em.sgfm.zip/1.43.0/scripts/generic_apache/ahs_get_serverStatusVal.pl line 22.

The script referenced in the alert does bugger all, it has a single line of code;

die "Please check the 'server-status' configuration in the httpd.conf file";

However the metric is still collected by the agent.

omcli status agent scheduler | grep -i non_windows_generic_apache_perf
2020-04-24 11:44:01.368 : omc_generic_apache:MyApacheServer:non_windows_generic_apache_perf

And you can still generate the error on the agent.

omcli getmetric agent MyApacheServer,omc_generic_apache,omc_PerformanceOverview
Oracle Management Cloud Agent
Copyright (c) 1996, 2020 Oracle Corporation.  All rights reserved.
EMD getmetric error: Please check the 'server-status' configuration in the httpd.conf file at /home/omcagent/200307.0800/plugins/oracle.em.sgfm.zip/1.48.0/scripts/generic_apache/ahs_get_serverStatusVal.pl line 22.

All this is despite the fact that the documentation says that performance metrics are supported.  https://docs.oracle.com/en/cloud/paas/management-cloud/monmr/apache-http-server.html

Generic Apache is such a fundamental entityType that I couldn't leave it there, after a bit of hacking in the scripts I worked out that the entity didn't have omc_version.  You can get your version from the server-status page.

Mine came back as;

<dl><dt>Server Version: Apache/2.4.6 ()</dt>

So the next problem was how to set it.  I tried editing the targets.xml file and adding

<Property NAME="omc_version" VALUE="Apache/2.4"/>

This didn't work although I expected it to.  So next I used the updateEntity REST API to add the value.

curl --location --request PATCH 'https://MyOMCInstance-MyOCITenant.omc.ocp.oraclecloud.com/serviceapi/entityModel/data/entities/AA3F54A39F7B852A73272AE687D1B638' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic c3RldmVXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXTokMG55YUYwMHQkMG55YUYwMHQx' \
--header 'Content-Type: text/plain' \
--data-raw '{
    "entityType": "omc_generic_apache",
    "entityName": "Myapache",
    "properties": {
        "capability": {
            "displayName": "Capability",
            "value": "monitoring"
        },
        "omc_server_status_connect_host": {
            "displayName": "Server status connection hostname",
            "value": "localhost"
        },
        "omc_server_root": {
            "displayName": "Server Root",
            "value": "/etc/httpd"
        },
        "omc_version": {
            "displayName": "Version",
            "value": "Apache/2.4"
        },
        "omc_httpd_conf_path": {
            "displayName": "Absolute directory path of httpd configuration file",
            "value": "/etc/httpd/conf/httpd.conf"
        },
        "omc_binary_home": {
            "displayName": "Binary Home",
            "value": "/usr/sbin"
        },
        "omc_is_remote": {
            "displayName": "Is Remote",
            "value": "no"
        },
        "omc_listen_port": {
            "displayName": "Listen Port",
            "value": "80"
        },
        "host_name": {
            "displayName": "Host Name",
            "value": "MyApache.xxxxxxx.oraclevcn.com"
        },
        "omc_protocol": {
            "displayName": "Protocol",
            "value": "http"
        }
    },
    "tags": {
        "tag_a": "blah"
    },
    "entityDisplayName": "MyApache",
    "namespace":"EMAAS"
}'

you could equally have used omcli update_entity.

After adding the omc_version this is what happens.

omcli getmetric agent MyApache,omc_generic_apache,omc_PerformanceOverview
Oracle Management Cloud Agent
Copyright (c) 1996, 2020 Oracle Corporation.  All rights reserved.
dataServedRate,idleWorkers,busyWorkers,busyWorkersUtilization
0.108,9,1,0

So now I have the metric collecting, all I need to do now is wait for them to appear in OMC.

Fighting with Oracle Management Cloud omcli getmetric

"omcli getmetric" is not displayed when you run "omcli help" but it does exist. It is mentioned in the documentation in the lack of data trouble shooting section https://docs.oracle.com/en/cloud/paas/management-cloud/moncs/lack-data.html

Here are a few of my gripes since long before omcli existed, the problems existed in emctl and have been carried forward into OMC as well, which is beyond frustrating.

So "omcli getmetric agent", which is the full command; wants three parameters "TARGETNAME,TARGETTYPE,METRICNAME" in that specific order but how do you know what TARGETNAME, TARGETTYPE and METRICNAME are ?

You could use "omcli config agent listtargets" which returns the TARGETNAME and TRAGETTYPE in the right order but you still don't have the METRICNAME;

omcli config agent listtargets
Oracle Management Cloud Agent  
Copyright (c) 1996, 2019 Oracle Corporation.  All rights reserved.
[myserver.test.oraclevcn.com:4459, Lama]
[myserver.test.oraclevcn.com, omc_host_linux]
[myserver_gateway1/managedServer1, omc_weblogic_j2eeserver]

Or you could use "omcli status agent scheduler" which will return TARGETTYPE, COLLECTIONITEM in the wrong order and something that you might assume to be METRICNAME, well you'd be wrong, the third parameter is actually the collection name. A collection is a group of one or more metrics.

omcli status agent scheduler
Oracle Management Cloud Agent  
Copyright (c) 1996, 2019 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Number of currently running scheduled items :: 0
Number of currently ready scheduled items :: 0
Number of scheduled items :: 57
Schedule Attempts Delay Percentage :: 0.000%
Running entries:: 
Ready entries:: 
Scheduled entries:: 
2019-10-09 14:33:25.412 : Lama:myserver.test.oraclevcn.com:4459:z#ConsumedvsExpected
2019-10-09 14:33:25.763 : HeapMonitorTask
2019-10-09 14:33:26.781 : AgentSystemMonitorTask
2019-10-09 14:33:32.660 : Lama:myserver.test.oraclevcn.com:4459:z#TaskExecutionRecordTotals
2019-10-09 14:33:32.820 : Lama:myserver.test.oraclevcn.com:4459:z#ThreadPoolStatistics
2019-10-09 14:33:33.391 : SchedulerHeartbeat
2019-10-09 14:33:33.391 : SenderManager.ReceiverHeartbeat
2019-10-09 14:33:35.044 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:jvm_memory_metrics
2019-10-09 14:33:35.057 : omc_host_linux:myserver.test.oraclevcn.com:LinuxHostProcesses
2019-10-09 14:33:35.101 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:work_manager_metrics
2019-10-09 14:33:35.120 : omc_host_linux:myserver.test.oraclevcn.com:LinuxHostPagingActivity
2019-10-09 14:33:35.132 : omc_host_linux:myserver.test.oraclevcn.com:LinuxHostDiskUsage
2019-10-09 14:33:35.175 : omc_host_linux:myserver.test.oraclevcn.com:LinuxHostNetworkUsage
2019-10-09 14:33:35.200 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:Threads
2019-10-09 14:33:35.209 : Lama:myserver.test.oraclevcn.com:4459:omc_CloudNetworkLatency
2019-10-09 14:33:35.214 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:jms_server_metrics
2019-10-09 14:33:35.225 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:jvm_garbage_collectors_metric
2019-10-09 14:33:35.275 : omc_host_linux:myserver.test.oraclevcn.com:LinuxHostUsage
2019-10-09 14:33:35.279 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:servlet_jsp_metrics
2019-10-09 14:33:35.286 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:web_module_metrics
2019-10-09 14:33:35.389 : LogCollector_odl
2019-10-09 14:33:35.392 : LogCollector_os_file
2019-10-09 14:33:35.394 : LoganalyticsManagerWatcher
2019-10-09 14:33:36.088 : DaemonManagerStatusWatcher
2019-10-09 14:33:37.549 : ZombieDetector.Task
2019-10-09 14:33:37.711 : Lama:myserver.test.oraclevcn.com:4459:z#ReceiverRates
2019-10-09 14:33:39.605 : Lama:myserver.test.oraclevcn.com:4459:z#DispatcherUtilization
2019-10-09 14:33:45.365 : Lama:myserver.test.oraclevcn.com:4459:z#SenderManager_IOTracking
2019-10-09 14:33:47.147 : Lama:myserver.test.oraclevcn.com:4459:HT_CPU
2019-10-09 14:33:50.062 : omc_host_linux:myserver.test.oraclevcn.com:LinuxHostFileSysUsage
2019-10-09 14:33:55.463 : Lama:myserver.test.oraclevcn.com:4459:z#SenderManager_ProcessingSize
2019-10-09 14:33:59.291 : Lama:myserver.test.oraclevcn.com:4459:z#DispatcherThroughput
2019-10-09 14:34:00.144 : Lama:myserver.test.oraclevcn.com:4459:HT_Memory
2019-10-09 14:34:00.541 : Lama:myserver.test.oraclevcn.com:4459:z#AgentStat_AgentHeapUsage
2019-10-09 14:34:03.583 : Lama:myserver.test.oraclevcn.com:4459:z#OMCSenderConnectionPool
2019-10-09 14:34:05.043 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:datasource_metrics
2019-10-09 14:34:05.067 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:Response
2019-10-09 14:34:07.344 : Lama:myserver.test.oraclevcn.com:4459:z#SenderManager_XferStatistics
2019-10-09 14:34:13.229 : Lama:myserver.test.oraclevcn.com:4459:z#SenderManager_Performance
2019-10-09 14:34:16.691 : Lama:myserver.test.oraclevcn.com:4459:z#TopTasks
2019-10-09 14:34:18.101 : Lama:myserver.test.oraclevcn.com:4459:Response
2019-10-09 14:34:18.775 : Lama:myserver.test.oraclevcn.com:4459:omc_GatewayNetworkLatency
2019-10-09 14:34:20.067 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:cpu_memory
2019-10-09 14:34:20.069 : omc_host_linux:myserver.test.oraclevcn.com:Response
2019-10-09 14:34:20.399 : Lama:myserver.test.oraclevcn.com:4459:z#RequestWorkingSet
2019-10-09 14:34:22.332 : Lama:myserver.test.oraclevcn.com:4459:z#RequestHandlerStats
2019-10-09 14:34:24.273 : Lama:myserver.test.oraclevcn.com:4459:DataProcessed
2019-10-09 14:34:50.043 : omc_weblogic_domain:myserver_gateway1:discoveryTriggerCollection
2019-10-09 14:34:50.045 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:ejb_pool_metrics
2019-10-09 14:35:05.044 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:connection_pool_metrics
2019-10-09 14:35:06.105 : Lama:myserver.test.oraclevcn.com:4459:UploadRate
2019-10-09 14:35:14.221 : Lama:myserver.test.oraclevcn.com:4459:z#AgentStat_TaskRollup
2019-10-09 14:35:27.696 : Lama:myserver.test.oraclevcn.com:4459:PendingUploads
2019-10-09 14:35:35.045 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:omc_ThreadPool
2019-10-09 14:36:34.079 : Lama:myserver.test.oraclevcn.com:4459:z#OMCSenderConnectionPoolUnreserved
2019-10-09 14:36:50.424 : Lama:myserver.test.oraclevcn.com:4459:PayloadRollup
2019-10-09 14:38:22.711 : CollectionManager.PersistSchedule
2019-10-09 14:38:33.817 : Lama:myserver.test.oraclevcn.com:4459:omc_TopTasks
2019-10-09 14:38:35.525 : Lama:myserver.test.oraclevcn.com:4459:z#CredentialStoreReads
2019-10-09 14:39:21.414 : Lama:myserver.test.oraclevcn.com:4459:AgentMetrics
2019-10-09 14:40:00.834 : Lama:myserver.test.oraclevcn.com:4459:z#CredentialStoreWrites
2019-10-09 14:40:42.973 : Lama:myserver.test.oraclevcn.com:4459:HarvesterStats
2019-10-09 14:40:52.993 : Lama:myserver.test.oraclevcn.com:4459:z#AgentStat_MetricCacheDepth
2019-10-09 14:41:32.437 : Lama:myserver.test.oraclevcn.com:4459:z#JobTaskRollupMetric
2019-10-09 14:41:36.931 : Lama:myserver.test.oraclevcn.com:4459:z#RequestDurationStatistics
2019-10-09 14:41:58.663 : Lama:myserver.test.oraclevcn.com:4459:QueueStats
2019-10-09 14:42:32.064 : Lama:myserver.test.oraclevcn.com:4459:z#AgentStat_TargetManagerEvents
2019-10-09 14:47:20.042 : omc_host_linux:myserver.test.oraclevcn.com:ProcessSetConfigTrigger
2019-10-09 14:47:51.069 : OrchestrationBacklogUpload
2019-10-09 22:04:35.052 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:application_server_config
2019-10-09 22:04:35.066 : omc_weblogic_j2eeserver:myserver_gateway1/managedServer1:HT_ResourceAllocation
2019-10-09 22:44:43.787 : Lama:myserver.test.oraclevcn.com:4459:Capabilities
2019-10-09 22:44:59.186 : Lama:myserver.test.oraclevcn.com:4459:HT_ResourceAllocation
2019-10-09 22:45:12.608 : Lama:myserver.test.oraclevcn.com:4459:TargetInstancesRollup
2019-10-09 22:46:13.126 : Lama:myserver.test.oraclevcn.com:4459:ConfigProperties
2019-10-09 22:49:11.897 : Lama:myserver.test.oraclevcn.com:4459:Product
2019-10-10 10:38:20.502 : PurgeTargetEvents
2019-10-10 10:38:27.730 : PurgeADR
2019-10-10 10:53:22.453 : ThresholdMgr.MCEResendTask
2019-10-10 12:18:20.044 : omc_host_linux:myserver.test.oraclevcn.com:LinuxHostConfig
2019-10-10 12:18:20.044 : omc_host_linux:myserver.test.oraclevcn.com:ProcessSetConfig

---------------------------------------------------------------
Agent is Running and Ready

COLLECTION_ITEMS are defined the XML definition file for the TARGETTYPE, these are located in "/u01/app/omcagent/190801.0800/plugins/oracle.em.sgfm.zip/1.45.0/default_collection".

The METRICNAME is defined by the <MetricColl> tag. You can view the defintion of the metric by looking in entity definition XML file which is located in "/u01/app/omcagent/190801.0800/plugins/oracle.em.sgfm.zip/1.45.0/metadata".

Collection definitions can be nested and reference other metric collections so you can't be sure that the metric will be in the file that you think.

For the purpose of this blog we will look at "cpu_memory" collection item for the Weblogic J2EE Server;

grep -H cpu_memory *wls*
omc_oracle_wls_capacity.xmlp:<CollectionItem NAME="cpu_memory" UPLOAD="1" DISABLED="FALSE">

Now lets take a look at the file "omc_oracle_wls_capacity.xmlp", this file actually contains;

<CollectionItem NAME="cpu_memory" UPLOAD="1" DISABLED="FALSE">
    <ValidIf>
        <CategoryProp NAME="monitoring_service" CHOICES="true"/>
    </ValidIf>
    <Schedule>
        <IntervalSchedule INTERVAL="1" TIME_UNIT="Min" />
    </Schedule>
    <MetricColl NAME="HT_CPU_int" />
    <MetricColl NAME="HT_CPU" />
    <MetricColl NAME="HT_Memory" />
</CollectionItem>

<CollectionItem NAME="HT_ResourceAllocation" UPLOAD="1" CONFIG="TRUE" DISABLED="FALSE">
    <ValidIf>
        <CategoryProp NAME="monitoring_service" CHOICES="true"/>
    </ValidIf>
    <Schedule>
        <IntervalSchedule INTERVAL="1" TIME_UNIT="Day" />
    </Schedule>
</CollectionItem>

The tag <MetricColl NAME=.... /> contains the name of the metric that you can interrogate using "omcli getmetric agent"

So for my example the command to run would be;

omcli getmetric agent apigwdev1_gateway1/managedServer1,omc_weblogic_j2eeserver,HT_Memory
Oracle Management Cloud Agent  
Copyright (c) 1996, 2019 Oracle Corporation.  All rights reserved.
totalPhysicalMemorySizeGB,memoryUsedGB,memoryUtilizationPercent,intervalSec

As you can see there is no output so the agent is having issues collecting this metric which is why I am not seeing data in the console.

Oracle Integration Cloud Log Analytics Audit Log Parser

At the time of writing Oracle Management Cloud currently comes with a Log Parser for Oracle Integration Cloud Audit logs (ics-audit.log).

The parser does not work if the userId contains a word separating characters like an email address.

The current parser definition is

\[{TIMEDATE}\]\s+\[(\w+)\]\s+\[(\w+)\]\s*\[(.*)?\]\s+\[(\S+)\]\s+\[\w+\:\s+(\d+)\]\s*\[\w+\:\s*(?:\<)?(\w+)(?:\>)?\]\s+\[\w+\:\s+(\S+)\]\s*\[\w+\:\s*([^\,]*)?\]\s*\[\w+\-\w+\:\s*(\w*)?\]\s*\[\w+\-\w+\:\s*(\w*)?\]\s+\[([^\,]*)\]\:\s*\[([^\,]*)?\,([^\,]*)?\,([^\,]*)?\,([^\,]*)?\,([^\,]*)?\,([^\,]*)?\](.*)?

The modified parser definition is

\[{TIMEDATE}\]\s+\[(\w+)\]\s+\[(\w+)\]\s*\[(.*)?\]\s+\[(\S+)\]\s+\[\w+\:\s+(\d+)\]\s*\[\w+\:\s*(?:\<)?(.*)(?:\>)?\]\s+\[\w+\:\s+(\S+)\]\s*\[\w+\:\s*([^\,]*)?\]\s*\[\w+\-\w+\:\s*(\w*)?\]\s*\[\w+\-\w+\:\s*(\w*)?\]\s+\[([^\,]*)\]\:\s*\[([^\,]*)?\,([^\,]*)?\,([^\,]*)?\,([^\,]*)?\,([^\,]*)?\,([^\,]*)?\](.*)?