I am attempting to emulate the Build Analyzer example with my own bucket and input stream. I believe I have set up everything correctly, but when I run test data, I do not get any results.
The entire log output is
[2013-03-29 08:57:16,988] INFO {org.wso2.carbon.databridge.core.DataBridge} - admin connected
Of course this makes sense when running in a production environment, but I have not been able to figure out how to increase the log level, ideally to some sort of trace mode, so I can see what is going on.
There are plenty of places to increase log levels, but unless I know which log levels to increase, I am afraid all I will do is add noise. How do I turn on appropriate logging in order to figure out what is going on?
As an aside, in my ideal world, there would be a place in the admin console where 1) all the streams and processes are mapped out (and verified) and 2) it would be possible to check a box to start tracing any stream.
TIA,
doug
The Build Analyser example is basically related to REST transport and email broker. The result of the example is an e-mail to a email account which you provide in the bucket configuration. To see the stream definitions you can go through the registry which is given in the management console of the CEP. We have given a graphical window to see the the events which are coming to CEP, In [1] of our documentation gives details about this. (To see the events graphically manner you must have proper input mapping for the bucket.
Yes I agree with you regarding logging. We are working on CEP to provide more user-friendliness to user in our future releases. Thank you for your thoughts and we'll take those in to our consideration.
[1] http://docs.wso2.org/wiki/display/CEP210/CEP+Server+Statistics
Cheers,
Mohan
Related
I am a total beginner in cloud service management, so this is a very basic question.
I have inherited a kubernetes based project running in Google Cloud. I have discovered recently that there are millions of errors I am unaware of in APIs & Services > Compute Engine API > Metrics menu:
I have tried searching for these values both on google in the docs to no avail. With no link to the list of logs and hundreds of sub menu items I feel completely lost on where to start.
How can I get more information about these errors?
How can I navigate to the relevant logs?
Your question is rather general so I will make some assumptions and educated guesses about your project and try to explain.
This level of error with API calls is of course unusually high and suggesting that some things don't work (for example someone deleted a backend service but left the load balancer without any health checks and it's accepting requests from the outside but there's nothing in the backend to process them).
That is just an exmaple - without more details I'm not even speculate further.
If you want to read more about the messages take the second one from the top - documentation for compute.v1.BackendServicesService.delete.
You can also explore other Compute Engine API methods to see what they do to give you more insight what is happening with your project.
This should give you a good starting point to explore the API.
Now - regarding logs. Just navigate to Logs Viewer and select as a resource whatever you want to analyse (all or a single VM, Load Balancer, firewall rule, etc). You can also include (or exclude) certain level of logs (warning, error etc). Pissibilities are endless.
Your query may look something like this:
Here's more documentation on GCP Logs Viewer to help you out.
I have seen some solutions for capturing client-side errors and reporting them to Stackdriver.
Does anybody know if it's possible to utilize Stackdriver in some way to collect page load timing metrics and report those? I couldn't find any example of how I might be able to do that in the documentation.
I believe a better approach is to send these information to your back end and have it forward them to stackdriver.
Otherwise, you have to either share credentials to the client to allow them to hit the stackdriver endpoint or open them as public. These are both horrible as someone could start hammering our logging and hide info/increase cost for you.
If you still want to go the "client logging directly" way, it's simply hitting the monitoring.googleapis.com endpoint with authenticated calls (here the auth is the hard part).
I would like to write debug information in my DM templates, but I cannot see nor find a way to generate print statements, logs, or anything to aid in debugging when something goes wrong with my template.
How do I add print or logging to deployment manager?
I checked, currently the only way to troubleshoot is to rely on the expanded template from the Deployment Manager Dashboard. You can check it in the following URL for a given deployment, but I guess you were already aware of this possibility:
https://console.cloud.google.com/dm/deployments/details/DEPLOYMENTNAME?project=PROJECTID
However a feature request has been opened and currently the engineering team is working and discussing the best way to provide to the customers this possibility.
https://issuetracker.google.com/80368273
I advise you to star the feature request in order to get updates via email and to place a comment in order to show the interest of the community.
All the official communication regarding that feature will be posted there.
Disclaimer: I work for Google Cloud Platform Support
I am trying to add some modification to the windows login screen that only allows a user to log in if they have time remaining for that day. I also want to allow them to increase the time via a connection with the wireless device.
I have seen similar things done, with Asus Face Login, and Bluetooth login, and I would have no problem writing the code, but how do I put the restrictions at the login screen?
Am I correct in the assumption that this can also only be done using C++? If so, I program mainly in java, so when environments would you recommend forC++?
Any suggestions and links to resources are appreciated!
Thanks
I am not pretty much sure but that can be done as follows:
There is task scheduler in windows that gives user a feature to run a particular program at log on. So you can develop a program that will run at log on.
Program can be something like that:
Firstly, it will get the current user, check for the time available with the user. This can be done by saving time spent by the user in internal database or file.
If user has crossed the specified limit then it will write the details in file/database and fire system("Logoff") command. Logoff is windows command to logoff.
Further on each successfull login it will keep the time of loging in and while logging off it will update the time difference in the file/database.
This is how I suppose it can be implemented. If you have some better way please share.
We had a debate in the office with respect to audit logging of messages received and sent via Web Services.
I am of the opinion that the entire SOAP message should not be logged in the application audit logs unless there is a requirement that states that this is required. Only salient elements of the request need to be part of the audit log as this provides evidence that is required in the audit trail.
My reasons are:
(1) Audit logs by definition are always turned on and should not be turned off. So if we take the decision of logging the entire message for audit trail they will be turned on always and can cause a huge performance impact during production runs (particularly during peak loads)
(2) If the business/technical requirement does not explicitly state this as a requirement this is an un-necessary overhead. If information is required, the run-time engines tracing capability can be used to turn on/off to get the SOAP messages.
What are the generic thoughts of experts in this space.
Thanks,
Manglu
Don't confuse auditing with logging. If there is a requirement for auditing then you need to perform auditing.
Since auditing is typically required for legal or policy reasons you need to understand what actions and activities need to be logged as well as what data needs to be logged. This is not a technical decision but needs to be determined by the business. Once you have your requirements then you can project your audit volumes and design your application to take these into account (e.g. performance, storage, etc.).
If you think you have an auditing requirement but it is not explicitly stated then ask for clarification. You don't want to find this out only after you have been sued.
If you truly have an auditing requirement then you should probably audit the entire soap request message as well as the response. This is to support non-repudiation.
As an example let's say that you have a health care application and only audit the key information: personal identifiers (e.g. SSN) and whether the patient is allergic to penicillin. But what happens when a patient dies because is allergic to penicillin was false when it shouldn't have been? The audit logs are checked and you say that you were sent a value of false for that patient but the other system says that they actually sent you a value of true and that you must have a problem with your system. In this scenario what you need to do is to show the exact message that was sent to the web service and that because it was signed by the service consumer you can prove that it came from them and also prove that the data in the message is correct. Then you would follow that information through your system via the audit logs.
Of course, it all goes back to the requirements; if the business finds that only auditing x and y satisfies whatever legislation or policies then go with that.
I know from experience that logging it all can lead to pretty huge files or a lot of data if kept on database. It's very helpful during development time, but in production it becomes a problem. I would suggest logging as you said. But be aware of a situation I came across: We were providing a webservice for 3rd-party companies use. When there's some dispute about who's fault is the error. We needed the exact SOAP message to prove that it wasn't our fault. I don't know if this scenario applies to you.