Hi Praveen,
I tested that on my box as well, works as expected.
Please enable DEBUG logging in the file
<HPBSM>\log\alerts\alerts.properties
change the line
alerts.loglevel=INFO
to
alerts.loglevel=DEBUG
safe the file,
wait 2 minutes,
then trigger the alert,
afterwards check the logfile C:\HPBSM\log\alerts\alerts.ejb.log,
hopefully it shows what's wrong.
Greetings
Siggi
Hi Adr,
thanks for your last reply and this information:
Exception in thread "AWT-EventQueue-2" java.util.MissingResourceException: Can't find bundle for base name AppServer/resources/AlertsAdminServerResources, locale en_GB
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1499)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1322)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:721)
at com.mercury.am.alerts.admin.ui.server.AlertsAdminServerImpl.getText(AlertsAdminServerImpl.java:514)
at com.mercury.am.alerts.admin.ui.server.AlertsAdminServerImpl.getGlobalSnmpv3UserName(AlertsAdminServerImpl.java:331)
...
This shouldn't (!) be a problem.
BSM looks for the file <HPBSM>\AppServer/resources/AlertsAdminServerResources_en_GB.properties (based on the locale settings of your browser), which doesn't exist:
C:\HPBSM\AppServer\resources>dir AlertsAdminSer*
09/07/2015 07:57 PM 2,070 AlertsAdminServerResources.properties
09/07/2015 07:57 PM 2,399 AlertsAdminServerResources_de.properties
09/07/2015 07:57 PM 2,070 AlertsAdminServerResources_en.properties
09/07/2015 07:57 PM 2,526 AlertsAdminServerResources_es.properties..
..
if BSM cannot find the file matching the locale it is supposed to fallback and use AlertsAdminServerResources.properties.
You can of course copy
AlertsAdminServerResources.properties
to
AlertsAdminServerResources_en_GB.properties
and try again, but I actually don't think that this will make a difference.
The other error seems to be more significant:
evb_alerts_ui.log (I've never seen this logfile before!!)
2016-09-22 14:10:46,847 [ajp-/127.0.0.1:8009-2] (AlertsAdminServerImpl.java:330) ERROR - Customer '1': Failed to get global SNMP v3 user name.
com.mercury.infra.setting.utils.SettingException: No such setting for customerID:1 context:alertengine setting:settings.global.snmp.event.user.name
at com.mercury.infra.setting.base.settingApi.SettingServiceAPIImpl.getVariablePerCustomer(SettingServiceAPIImpl.java:205)
No idea if this can cause the GUI not to come up, but you can cure this easily by going to
BSM -> Admin -> Platform -> Setup and Maintenance -> Infrastructure Settings
Foundations : Alerting
and then under
Alerting - Triggered Alerts
fill in somethiung useful for all the SNMP-related fields:
Alerting - Triggered alerts
Default SNMP v3 authentication passphrase
<something (stars)>
Default SNMP v3 authentication protocol
No authentication
Default SNMP v3 privacy passphrase
<something (stars)>
Default SNMP v3 privacy protocol
No privacy
Default SNMP v3 user name
HPBSMUSER
see my - out of the box - settings under each line.
On my box
"Default SNMP v3 user name" is set to "HPBSMUSER".
If you specify something here, it might do the trick already.
The GUI will tell you if a restart of BSM is required after chaning that variable.
Greetings
Siggi
Stupid me,
yes, you are correct,
<HPBSM>\log\alerts\alerts.properties
is supposed to be
<HPBSM>\conf\core\Tools\log4j\EJB\alerts.properties
Sorry
Siggi
Hi Adr,
what you illustrate is the reason for the issue.
You should see the same settings under "Alerting - Triggered alerts" as I can see on my box:
All the SNMP v3 Settings are missing (Default and Legacy), leading to the problem that BSM fails when it tries to access the setting via the internal key,
like as "Default SNMP v3 user name" == "global SNMP v3 user name" via setting for customerID:1 context:alertengine setting:settings.global.snmp.event.user.name
I checked around and found the default settings in the file <HPBSM>\conf\settings\alertengine.xml
..
<setting nameResource="settings.default.snmp.user.name.name" name="settings.default.snmp.user.name" displayInUI="true" descResource="settings.default.snmp.user.name.desc" sectionResource="sections.alert.actions" refreshRate="Minutes" refreshRateValue="1" settingType="customer">
<value type="string"> HPBSMUSER </value>
</setting>
..
<setting nameResource="settings.global.snmp.event.user.name.name" name="settings.global.snmp.event.user.name" displayInUI="true" descResource="settings.global.snmp.event.user.name.desc" sectionResource="sections.alert.actions" refreshRate="Minutes" refreshRateValue="1" settingType="customer">
<value type="string"> HPBSMUSER </value>
</setting>
..
Can you please verify if you can find at least these two entries in this file.
If they are there, then we need to find a way to tell BSM to read it and to add the entries to the database.
If they are not in, the file needs to be replaced with a good one, and re-read by BSM (as above).
I guess that the second case applies to your system.
Another option would be to manually add these entries to the BSM Management database table,
while BSM keeps the default Infrastructure Settings "somewhere" (I assume in the corresponding xml files) and only keeps changes in the SETTING_PARAMETERS table.
Greetings
Siggi
P.S.: What did you do to your system? This is really, really strange!
Hi Praveen,
thanks for the update and for providing all the data.
After checking alerts.ejb.log I can see that enabling DEBUG logging odesn't help a lot,
but at least a little bit.
we have these entities and fail with one (or more) of them:
2016-09-22 09:01:39,996 [pool-AlertMDBContext-thread-73] (AlertHandler.java:53) DEBUG - Customer [1] handling alert [9f4636755bbbfb9af5ebb152f54c4a9a] in [REGULAR_MODE] mode
(TriggeredDataContainer.java:144) DEBUG - adding data to group
[0x30c504e6e09f01ff030d1b73b43f78b3|0x1b4d76f75f237c7633aff210d918804e|]:
[groupBy:
0x30c504e6e09f01ff030d1b73b43f78b3
0x1b4d76f75f237c7633aff210d918804e
szTransactionName=100_TableauServer_Workbooks
u_iScriptId=322
u_iBTFId=0x6a9307a407c3f1f0e48f6ff86944558c
u_iTransactionId=0x30c504e6e09f01ff030d1b73b43f78b3
u_iBpmAgentId=1986
u_iLocationId=0x1b4d76f75f237c7633aff210d918804e
application_id=0xf910d384933852aaa77bd094240052ed
2016-09-22 09:01:41,000 [pool-AlertMDBContext-thread-73] (TriggeredDataContainer.java:292) DEBUG - creating new message, current state:[T][E][E][E][E]
2016-09-22 09:01:41,000 [pool-AlertMDBContext-thread-73] (AlertTask.java:145) ERROR - Customer ID: 1 Alert ID: 9f4636755bbbfb9af5ebb152f54c4a9a MERQ-120630: Exception was throws while processing an alert, the alert may not be sent
Details=id: 9f4636755bbbfb9af5ebb152f54c4a9a, customer id: 1
java.lang.NullPointerException
at com.mercury.am.eum.alerts.common.extendedproperties.ExtendedPropertiesUtils.addGroupByToCommonMap(ExtendedPropertiesUtils.java:87)
at com.mercury.am.eum.alerts.common.extendedproperties.BpmTransExtendedPropsProvider.getExtendedPropertiesMap(BpmTransExtendedPropsProvider.java:39)
at com.mercury.am.eum.alerts.common.extendedproperties.EUMAlertsExtendedPropertiesHandler.enrichAlertMessageDetails(EUMAlertsExtendedPropertiesHandler.java:33)
The only ideas I have are as follows:
- check whether or not all CIs the alert uses exist in RTSM:
0x30c504e6e09f01ff030d1b73b43f78b3 <- that's the transaction
0x1b4d76f75f237c7633aff210d918804e <- that's a location
BTF
0x6a9307a407c3f1f0e48f6ff86944558c
Transaction
0x30c504e6e09f01ff030d1b73b43f78b3
Location
0x1b4d76f75f237c7633aff210d918804e
Application
0xf910d384933852aaa77bd094240052ed
To check, go to BSM -> Admin -> RTSM -> IT Universe Manager -> Modeling
CI Selector -> Search CIs
in the field "CI Name" enter the CI ID (omit the 0X)
here enter one CI ID after the other and check whether it exists or not.
Here is an example from my system:
(TriggeredDataContainer.java:144) DEBUG - adding data to group [0xb8506be7abd403959e6d5f74899bbe97|0xe4e4c72c6e0a43d9745c0106df67dd2b|]:
so I check for 0xb8506be7abd403959e6d5f74899bbe97 and enter "b8506be7abd403959e6d5f74899bbe97" and see that it's a Business Transaction.
I assume that at least one of the elements do NOT exist in RTSM.
Greetings
Siggi
And the screenshot
Hi kikazu,
you didn't mention your BSM version and your server distribution.
While 20 minutes sounds like a lot, I do have one BSM 9.26 IP1 environment (2 x GW, 2 x DPS) where stopping BSM takes a long time.
I just checked the log (<HPBSM>\log\supervisor\nannyStatus.log),
as you can see, it takes 15 minutes on the primary GW, the majority of the time is spend in stopping OPR, OPR-SCRIPTING-HOST and bpi_process_repos
2016-09-16 17:43:45,855 User operation - stop nanny
2016-09-16 17:43:46,868 businessImpact_service STOPPING
2016-09-16 17:43:52,568 businessImpact_service STOPPED
2016-09-16 17:43:52,584 pi_engine STOPPING
2016-09-16 17:43:58,794 pi_engine STOPPED
2016-09-16 17:43:58,810 OPR STOPPING
2016-09-16 17:48:40,798 OPR STOPPED
2016-09-16 17:48:40,813 OPR-SCRIPTING-HOST STOPPING
2016-09-16 17:53:24,283 OPR-SCRIPTING-HOST STOPPED
2016-09-16 17:53:24,298 bpi_process_repos STOPPING
2016-09-16 17:58:07,815 bpi_process_repos STOPPED
2016-09-16 17:58:07,830 offline_engine STOPPING
2016-09-16 17:58:09,049 offline_engine STOPPED
2016-09-16 17:58:09,065 basel_engine STOPPING
2016-09-16 17:58:10,643 basel_engine STOPPED
2016-09-16 17:58:10,658 marble_supervisor STOPPING
2016-09-16 17:58:12,799 marble_supervisor STOPPED
2016-09-16 17:58:12,815 marble_matcher STOPPING
2016-09-16 17:58:14,049 marble_matcher STOPPED
2016-09-16 17:58:14,065 marble_worker_1 STOPPING
2016-09-16 17:58:15,190 marble_worker_1 STOPPED
2016-09-16 17:58:15,205 marble_loader STOPPING
2016-09-16 17:58:16,377 marble_loader STOPPED
2016-09-16 17:58:16,393 pmanager STOPPING
2016-09-16 17:58:17,533 pmanager STOPPED
2016-09-16 17:58:17,549 mercuryAS STOPPING
2016-09-16 17:58:35,018 mercuryAS STOPPED
2016-09-16 17:58:35,033 odb STOPPING
2016-09-16 17:58:36,658 odb STOPPED
2016-09-16 17:58:36,674 hornetq STOPPING
2016-09-16 17:58:38,674 hornetq STOPPED
2016-09-16 17:58:38,674 All services stopped in 14m:51s
although there is not a lot of activity going on.
Similaer to DPS2 (failover):
it takes 10 minutes, most of the time is spend in the same processes as on DPS1
2016-09-16 17:47:32,399 OPR STOPPING
2016-09-16 17:50:44,969 OPR STOPPED
2016-09-16 17:50:44,980 OPR-SCRIPTING-HOST STOPPING
2016-09-16 17:53:56,845 OPR-SCRIPTING-HOST STOPPED
2016-09-16 17:53:56,858 bpi_process_repos STOPPING
2016-09-16 17:57:08,164 bpi_process_repos STOPPED
GW1 and GW2: roughly 4 minutes
another BSM 9.26 IP2 (typical installation) takes less than 8 minutes to stop.
I assume that it simply takes a lot of time to synchronize the BSM parts on the servers during the shutdown.
Greetings
Siggi
Hi Mark_Ji,
you would need to set the correct loglevel in the corresponding log4j.properties file.
The Monitor Reference manuals, Chapter 17: Custom Monitor, states:
..
Custom Monitor Logs
- Errors in the monitor (including errors in the script) are written to the SiteScope logs in the same way as for
any other monitor. Check the error.log and RunMonitor.log files.
- Error messages from the script are displayed in the custom_monitor.log file located in <SiteScope root
directory>\logs\custom_monitors. This log can be used for info, warning, error, and debug messages
from running the script.
To change the log level to DEBUG mode, in <SiteScope root directory>\conf\core\Tools\log4j\PlainJava\log4j.properties,
change ${loglevel} to DEBUG in the following paragraph:
# Custom monitors category
log4j.category.CustomMonitor=${loglevel},custom.monitor.appender
log4j.additivity.CustomMonitor=false change
..
To change the logvel to for example DEBUG, you either need to change the global variable
#loglevel can be any of DEBUG INFO WARN ERROR FATAL
loglevel=ERROR
to for example
#loglevel can be any of DEBUG INFO WARN ERROR FATAL
loglevel=DEBUG
This however would apply to whole SiteScope,.
To set it for all custom monitors only change
from
log4j.category.CustomMonitor=${loglevel},custom.monitor.appender
to for example
log4j.category.CustomMonitor=DEBUG,custom.monitor.appender
Greetings
Siggi
Hi Adr,
I don't have any better advise than opening a case with HPE Support, I ran out of ideas.
Greetings
Siggi
Hi Praveen;
did you already delete the alert and re-create it from scratch, but the issue still occurs?
Do this occur for all EUM alerts with the same data grouping configuration?
If it's a yes, then please go ahead and open a case with Support.
Greetings
Siggi
Hi Praveen,
I tested the files you send me on my BSM 9.26 IP2 system,
BSM still generates emails fine for EUM alerts with
Data Grouping on Transaction and Locations
no errors in alerts.ejb.log ...
Greetings
Siggi
Hi Praveen,
here we go:
BAC_00906 - BSM 9.26.481 Build Patch (9.26 IP2) Windows 64-bit
https://softwaresupport.hpe.com/group/softwaresupport/search-result/-/facetsearch/document/LID/BAC_00906
BAC_00907 - BSM 9.26.481 Build Patch (9.26 IP2) for Linux 64-bit
https://softwaresupport.hpe.com/group/softwaresupport/search-result/-/facetsearch/document/LID/BAC_00907
Greetings
Siggi
Hi SK3210,
did you follow the procedure as described in
BSM 9.26 BSM Installation Guide -> Chapter E: Disaster Recovery for BSM
-> Cleanup Procedure
steps 1 ,2, 4 - 11
This is what needs to be done if you change the hostname of the server(s) running BSM.
Greetings
Siggi
Hi Adr,
this looks like a plain and easy network issue (well):
the host "Ukmlwbac003", is this the BPM server?
Can you check whether you can reach the BPM server from the BSM system,
and the other way around, by simply opening the BPM / BSM GUI?
From BPM you also can check
http://<GW_server>/topaz/topaz_api/api_getservertime.asp
comes back with -
1^**^1
time
17/04/2008 10:23:43
http://<GW_server>/ext/mod_mdrv_wrap.dll?type=test
comes back with -
Web driver is up. Time is: 1208446128
http://<GW_server>/topaz/topaz_api/api_reporttransactions_ex.asp
comes back with -
0
From all the other errors it seems there is more on your box that (just) a networking error,
for example that - as per jboss-aal.log BSM cannot talk to BSM_DT is a bad sign,
and it also makes me assume that the BSM - BPM server connection works in general.
Do you have anything configured in the EUM area already?
As you have very similar errors, can you reproduce one of them, and then check the logs afterwards?
In all cases the errors look quite different, a connection time out, but as far as I know for checking the settings or the license information BSM checks the configuration on the BSM side (DB or calls to modules which check the DB) and doesn't talk to the BPM agent.
Greetings
Siggi
Great,
good to hear.
Greetings
Siggi
Hi SAM-0928,
SDR is part of BSM and doesn't require extra licensing. Depending on the type of upgrade (direct vs staging) enaling SDR is part of the upgrade procedue.
The BSM Upgrade manual(s) cover all this in detail.
Greetings Siggi
Hi Bharath,
if it's you are the Bharath I now have three SiteScope - BSM - Toplogy cases with, then I don't have further help.
If you are another Bharth, we currently have two hotfixes for this issue, but it depends what exact issue you experience.
Greetings
Siggi
Hi Praveen,
you can apply IP2 on top of BSM 9.26 directly, there is no need to first install IP1 and then IP2.
Greetings
Siggi
This has been answered in the SiteScope Forum via
/t5/SiteScope-Support-Customer-Forum/list-of-supported-TLS-ciphers-for-SiteScope-v11-23/td-p/6902548
Greetings
Siggi
Hi gmatrozos,
when looking at the Sitecope manual, it states
..
Additional information to describe a monitor. This can include the most common
HTML tags for text styling, such as <BR>, <HR>, and <B>. The description is
displayed only when viewing or editing the monitor's properties in the SiteScope
Dashboard.
..
so it's mainly a SiteScope thing.
Where exactly do you look at the description (what report / menue) in BSM?
What BSM version do you use?
I assume that BSM simply cannot interpret HTML code in that very field and displays the text as it sees it, plain, without any formatting.
Greetings
Siggi