I am trying to use LOGEVENT appender to send ERROR logs to BAM for alerts and notification. LOGEVENT is configured in log4j.properties. However, I am facing 2 issues -
a. Stream name is generated with following convention : _ e.g. log_0_ESB_2014_09_29
b. IP address of ESB is not captured. Cassandra explorer shows "Non displayable value"
Please advise, if stream name can be generated as e.g. "ESB_Stream" without date part and IP address can be published with text value.
log4j.properties snippet :
log4j.appender.LOGEVENT=org.wso2.carbon.logging.appender.LogEventAppender
log4j.appender.LOGEVENT.url=tcp://localhost:7611
log4j.appender.LOGEVENT.layout=org.wso2.carbon.utils.logging.TenantAwarePatternLayout
log4j.appender.LOGEVENT.columnList=%T,%S,%A,%d,%c,%p,%m,%H,%I,%Stacktrace
log4j.appender.LOGEVENT.userName=admin
log4j.appender.LOGEVENT.password=admin
log4j.appender.LOGEVENT.processingLimit=1000
log4j.appender.LOGEVENT.maxTolerableConsecutiveFailure=20
log4j.appender.LOGEVENT.threshold=WARN
At the moment you cannot configure the stream definition name, and it gets created dynamically per tenant per date per instance type. However, we have decided to add this feature for our next releases[1]
Regarding the IP not getting populated issue, we have identified this issue[2] and we have fixed it for our next
Please refer the below public jiras.
[1] - https://wso2.org/browse/CARBON-14851
[2] - https://wso2.org/jira/browse/CARBON-14991
Related
I have "export" proxy service which aims to "obtain" sequence. The sequence points to ${server}/services/sapBapi or "sapBapi" proxy service. The "sapBapi" proxy service points to gov:endpoints/sapbapiendpoint.xml endpoint, where is the concrete address: bapi:/abc
I have abc.dest and abc.server property files with SAP endpoint parameters on path
$WSO2_HOME/repository/conf/sap according to official documentation here
When I want to use "export" proxy service and send data, I will find this in logs:
DEBUG - Started sending message to uri=bapi:/abc/services/sapBapi/services/export {org.wso2.carbon.transports.sap.SAPTransportSender}
WARN - JCo configuration file for the destination : abc/services/sapBapi/services/export does not exist - Please specify the JCo configuration in $WSO2_HOME/conf/sap/abc/services/sapBapi/services/export.dest or abc/services/sapBapi/services/export.dest {org.wso2.carbon.transports.sap.CarbonDestinationDataProvider}
ERROR - Error while sending request to the EPRbapi:/abc/services/sapBapi/services/export {org.wso2.carbon.transports.sap.SAPTransportSender}
com.sap.conn.jco.JCoException: (106) JCO_ERROR_RESOURCE: Destination abc/services/sapBapi/services/export does not exist
When I put export.dest file to path $WSO2_HOME/repository/conf/sap/abc/services/sapBapi/services/, then it works perfectly.
My questions:
Why is it using proxy service name ("export") for the .dest property
file in described case?
Why is it searching for .dest property file
on path $WSO2_HOME/conf/sap/abc/services/sapBapi/services/ instead
of $WSO2_HOME/repository/conf/sap/?
WSO2 version: 6.5.0
I don't know WSO2 Enterprise Integrator, but obviously an instance of class org.wso2.carbon.transports.sap.CarbonDestinationDataProvider is the registered DestinationDataProvider at the JCo runtime. This is the instance that decides alone from where to obtain the logon parameters for a JCoDestination based on the destination name string that it gets from the JCoDestinationManager.
From your example error message, this destination name string seems to be "abc/services/sapBapi/services/export" in this case for which the org.wso2.carbon.transports.sap.CarbonDestinationDataProvider is searching a property file with name abc/services/sapBapi/services/export.dest
I hope this info will help you to adapt your code/configuration to fit your expectations.
"The bind address of this member. The difference between localMemberHost & localMemberBindAddress
is that localMemberHost is the one that is advertised by this member, while localMemberBindAddress
is the address to which this member is bound to."
We are in the process of making API Manager components HA ready. As a result of that, we are upgrading configurations as per the cluster guide. HazelcastClusteringAgent configs are getting updated as well. As I quoted at the top most section provided comment is bit unclear, much appreciated if you can eloborate more. Furthermore, would like to know that, this is still a valid set of parameters that need to be fulfilled if we are following the AWS clustering configs for Hazelcast.
In the event of AWS clustering the bind address is constructed (if using aws discovery) by the resulting IP address returned from the ec2:describe instances and the configured listen port (5701 default). So you would not set the bind address it is set by the plugin.
A customer is running one of our programs, usually run as a service, as an application. The customer is getting the following error on CoRegisterClassObject():
The class is configured to run as a security id different from the caller.
It looks like some type of session 0 error, but why should CoRegisterClassObject() care about session 0? COM should allow both services (session 0) and apps (session > 0) and not care what registers what, shouldn't it?
Also, I don't like the fact that it's not in the list of errors returnable by CoRegisterClassObject(), as per the Microsoft doc webpage.
The error code in question is CO_E_WRONG_SERVER_IDENTITY (0x80004015).
Per this page:
COM security frequently asked questions
Q6 Why does CoRegisterClassObject return CO_E_WRONG_SERVER_IDENTITY? When launching my ATL 1.1 server service as an .exe file, I receive CO_E_WRONG_SERVER_IDENTITY from CoRegisterClassObject. (The class is configured to run as a security ID different from the caller.) This seems to occur whether I skip the CoInitializeSecurity or not. It fails running as a service or as an .exe file.
A. Many services are debugged by running them as console applications in the interactive user identity. Because the service is already registered to run in a different identity (configurable by the Services control panel applet), OLE fails the CoRegisterClassObject and RunningObjectTable::Register(ROTFLAGS_ALLOWANYCLIENT) calls by returning CO_E_WRONG_SERVER_IDENTITY to enforce security and to prevent malicious servers from spoofing the server. To debug by running in the interactive user's identity, make the following changes in the server's registry entries to prevent these failures:
• To prevent CoRegisterClassObject failure, remove the following named value:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
"LocalService"="HelloOleServerService"
• To prevent a IRunningObjectTable::Register(ROTFLAGS_ALLOWANYCLIENT) failure, follow these steps:
Remove the following named value:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
"LocalService"="HelloOleServerService"
Then add the following named value:
[HKEY_CLASSES_ROOT\APPID\{0bf52b15-8cab-11cf-8572-00aa00c006cf}]
"RunAs"="Interactive User"
You muist restore the modified registry entries after debugging.
I am assuming you would have to replace {0bf52b15-8cab-11cf-8572-00aa00c006cf} with your COM object's actual CLSID instead.
I have created a console app and managed to upload it to the cloud, and I have scheduled it to run every 15 minutes. The console app runs for the first time with success as result and thens fails stating an error in the connection string. Could someone shed light on this please. Would be greatly apprecited.
Thanks
The error message follows:enter image description here
Make sure that you are setting a connection string named AzureJobsRuntime in your Windows Azure Website configuration with a value similar to DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY pointing to the Windows Azure Storage account where the Windows Azure WebJobs Runtime logs are stored.
Please visit the article about configuring connection strings for more information on how you can configure connection strings in your Windows Azure Website.
To clarify a couple of possible gotchas (adding to the accepted answer):
Set these values by going to
App Services -> Your Web App -> Settings / "All Settings" -> Application Settings -> (In page under header) Connection strings
There you'll find Name, Value, and a Type drop down.
Name: Do NOT put your storage account name here! Rather, this is where you put AzureWebJobsDashboard for one connection string and on the next AzureWebJobsStorage. The value for these should look like:
DefaultEndpointsProtocol=https;AccountName=<mysupercoolblobstorageaccountname>;AccountKey=<blahblah==>
-- Old Portal --
I've had problems with this before where it was fixed in the old portal, so for that sake:
Old Portal: Your website -> Configure tab -> under 'connection strings', enter two new values: a) dropdown type CUSTOM, for NAME do NOT enter the name of your storage account! rather Name is: 'AzureWebJobsDashboard' or for the other (enter two entries): 'AzureWebJobsStorage'.
You need to set AzureJobsRuntime as a connection string (for an Azure storage account), you can do that on the Azure portal under: Websites --> Your Website --> CONFIGURE tab --> connection strings.
Web Job is not able to figure out the connectionString value in appsettings.json file. There could be two scenario:
If you are using an emulator, try adding this in your appsettings.json file
{
"ConnectionStrings": {
"AzureWebJobsDashboard": "UseDevelopmentStorage=true",
"AzureWebJobsStorage": "UseDevelopmentStorage=true"
}
}
If you are trying to connect directly to your Azure portal
{
"ConnectionStrings": {
"AzureWebJobsDashboard": "url",
"AzureWebJobsStorage": "url"
}
}
I have a web service (with WSDL) with mule to be used by people.
I want to get some information about users that use my web-service. For example : ip and time-stamp of the API invocation.
Also, I want to know how much has web-service been used in mule?
I don't think there's such statistical information. However, you could add a logger processor to the flow (assuming it's a flow) marking something like "Web Service XXX was called." The logged message would also contain the timestamp, because of the logger formatter.
As to the IP that called the service, Mule places the calling address in the message Inbound property remoteAddress. So, you could just add this line to the flow:
<logger message="Incoming message. Caller Address: #[message.inboundProperties['remoteAddress']]"/>
This would log each access (which could be used for statistical purposes by an analyzing tool) and their respective calling address.
This sounds a good use case for either:
A custom interceptor, that takes care of storing usage statistics,
A wire-tap that sends to a flow in charge of storing usage statistics.