Azure Gateway WAF - Diagnostics Issue - azure-log-analytics

I'm trying to setup Azure WAF (v2) on my App Gateway (currently in detection mode first to handle false positive cases), however, I'm seeing this warning:
To view your detection logs, you must have diagnostics enabled.
So, I went to Diagnostic settings and created it there with following options:
Log:
ApplicationGatewayAccessLog - (checked)
ApplicationGatewayPerformanceLog - (checked)
ApplicationGatewayFirewallLog - (checked)
Metric:
AllMetrics - (checked)
I have Send to Log Analytics checked as well. Also Archive to a storage account enabled.
But I'm still seeing the same warning mentioned above.
Any idea what I might be missing here?
UPDATE, I do see records within log with following query, but warning is still there:
AzureDiagnostics | where OperationName == "ApplicationGatewayFirewall"

Related

How to troubleshoot enabling API services in GCP using gcloud

When executing terraform apply, I get this error where I am being asked to enable IAM API for my project.
Error: Error creating service account: googleapi: Error 403: Identity and Access
Management (IAM) API has not been used in project [PROJECT-NUMBER] before or it is
disabled. Enable it by visiting
https://console.developers.google.com/apis/api/iam.googleapis.com/overview?
project=[PROJECT-NUMBER] then retry. If you enabled this API recently, wait a few
minutes for the action to propagate to our systems and retry.,
accessNotConfigured
When I attempt to enable it using gcloud, the service enable just hangs. Is there any way to get more information?
According to the Google Dashboard, everything is green.
I am also seeing the same issue using the UI.
$ gcloud services enable iam.googleapis.com container.googleapis.com
Error Message
ERROR: gcloud crashed (WaitException): last_result=True, last_retrial=178, time_passed_ms=1790337,time_to_wait=10000
Add --log-http to (any) gcloud command to get detailed logging of the underlying API calls. These may provide more details on where the error occurs.
You may wish to explicitly reference the project too: --project=....
Does IAM need to be enabled? It's such a foundational service, I'm surprised anything would work if it weren't enabled.

re-configuring a worklight application with analytics

After redeploying a worklight application, some configuration for analytics got lost and I'm trying to configure worklight with analytics again.
The dashboard shows "No data available" for time after the deployment although there are old records displayed for the time before the deployment of the application. So the db was not affected.
I set the wl.analytics.logs.forward property to "true" in worklight.properties;
also I set the wl.analytics.url of the db to be something like:
https://myserver:port/analytics/data
The dashboard is on
https://myserver:port/analytics/console
That is the URL for the analytics server.
Although if I put the db URL in a browser I get something like:
Error 404: java.io.FileNotFoundException: SRVE0190E: File not found: /data
Checked SystemOut.log and SystemErr.log (WAS logs) and I did not see errors there.
Does anybody know which is the XML I need to check in order to validate the configuration is OK for analytics? How could I troubleshoot this problem? Are there other logs I could check?
In the list of environment variables you gave I do not see any for username and password. Try to set:
wl.analytics.password=admin
wl.analytics.username=admin
It would be useful to see a wireshark trace, maybe you are not getting 403s. The Analytics data uploader generally has a small bit of protections and you have the option to keep or remove it.
#patbarron is correct about the multiple WAR files though. You need to send your analytics data to the /analytics-service context. The WAR analytics-service is the WAR that handles all the data processing, querying, etc. The other WAR analytics just handles the console UI.
When testing it might be beneficial to lower the
wl.analytics.queue and wl.analytics.queue.size, those values are for collecting data on the MobileFirst runtime server. Data is collected at the runtime server then sent to the analytics server. The larger these values are generally, the longer it will take to send. There are good to set for production

Repeated IBM bluemix Node Red app crashing; status 1

My Node Red application in IBM BlueMix is repeatedly crashing - once an hour - with no real error message other than "exited with status: 1."
How can I troubleshoot this issue?
Is there someone from IBM BlueMix support that monitors this that could take a look?
I looked at my logs and there's nothing in there that really says what's going on.
Edit per requests:
The regular log for "OUT/ERR" is scrolling so fast with HTTPD logs that I can't get it to copy/paste. Filtering to "ERR" Channel the only thing I see is below. I believe this is an error which occurs during deploy when the application restarts.
[App/0] ERR js-bson: Failed to load c++ bson extension, using pure JS version
My Node Red application is gathering data from Wink, LIFX, and other IoT services and compiles them together into a Freeboard dashboard.
Caught crash on screenshot here -- not enough cred to post images so it'll only post as a link
The zlib error was fixed in the 0.13.2 Node-RED release (that shipped 19/02/16).
If you re-stage your application is should pick up the new version of Node-RED
You can re-stage the application using the cf command line management application:
cf restage <app name>

Simulate Access disable feature in Worklight , when worklight server itself is down.

I am trying show end users maintainence window such as "we are down please try later" and disable the application but my problem is what if my worklight server itself is down and not reachable and i cannot use the feature provided by worklight console,
Is there a way i make my app talk to a different server which returns back the below json data when a app is disabled , can i simulate this behaviour is this possible.
json recieved on access disabled in worklight :-
/*-secure-
{"WL-Authentication-Failure":{"wl_remoteDisableRealm":{"message”:”We are down, Please try again soon","downloadLink":null,"messageType":"BLOCK"}}}*/
I have some conceptual problems with this question.
Typically a production environment (simplified) would not consist of a single server serving your end-users... meaning, there would be a cluster of nodes, each node being a Worklight Server, and this cluster would be behind a load balancer that would direct the incoming requests. And so in a situation where a node is down for maintenance like in your scenario there would still be more servers able to serve - there would be no down time.
And thus at this point your suggestion to simulate a Remote Disable by sending it from another(?) Worklight Server seems not so much the correct path to take (it may even be simply wrong). Have you had this second Worklight Server, why wouldn't it just serve the apps business like usual? See again my first paragraph about clustering.
Now lets assume there is still a downtime, that affects all servers. The application's client logic should be able to handle failed connections to the Worklight Server. In such a case you should handle this in the WL.Client.connect()'s onFailure callback function to display a WL.SimpleDialog that looks just like a Remote Disable's dialog... or perhaps via the initOption.js's onConnectionFailure callback.
Bottom line: you cannot simulate the JSON that is sent back for the wl_RemoteDisable realm; it is part of a larger security mechanism.
Additionally though, perhaps a way to better handle maintenance mode on your server is to have the HTTP server return a specific HTTP status code, check for this code and display a proper message based on the returned HTTP status code.
To check for this code in a simple example:
Note: the getStatus method is available starting MobileFirst Platform Foundation 7.0 (formerly "Worklight").
function wlCommonInit(){
WL.Client.connect({onSuccess:success, onFailure:failure});
}
function success(response) {
// ...
}
function failure(response) {
if (response.getStatus() == "503") {
// site is down for maintenance - display a proper message.
} else if ...
}

Worklight v6 iwap

I set up Worklight V6 Server and IWAP.
I found my worklight app console has analytics tab and there is IWAP console.
there is dashboad view, search view, search log view, geo analytics view.
then I put WL.Logger.error and WL.Analytics.log code in my app and issued these logs
but I cannot find any data on my IWAP console.
and there is following NumberFormatException in my IWAP logs. can I fix this?
[2013-06-24 18:02:35,998][DEBUG][action.search.type ] [Rattler] [worklight][7], node[M8YymIEGQbae4fbtkc2cyA], [P], s[STARTED]: Failed to execute [org.elasticsearch.action.search.SearchRequest#465651a2]
org.elasticsearch.search.SearchParseException: [worklight][7]: from[0],size[-1],sort[<custom:"worklight_data.timestamp": org.elasticsearch.index.field.data.longs.LongFieldDataType$1#79b8644>!]: Parse Failure [Failed to parse source [{"sort": {"worklight_data.timestamp": {"order": "desc"}}, "from": 0, "script_fields": {}, "facets": {}, "query": {"query_string": {"query": "worklight_data.log.message:* AND worklight_data.timestamp:[NaN TO * ]"}}, "size": 1000}]]
at org.elasticsearch.search.SearchService.parseSource(SearchService.java:566)
at org.elasticsearch.search.SearchService.createContext(SearchService.java:481)
at org.elasticsearch.search.SearchService.createContext(SearchService.java:466)
at org.elasticsearch.search.SearchService.executeQueryPhase(SearchService.java:236)
at org.elasticsearch.search.action.SearchServiceTransportAction.sendExecuteQuery(SearchServiceTransportAction.java:141)
at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.sendExecuteFirstPhase(TransportSearchQueryThenFetchAction.java:80)
at org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction.performFirstPhase(TransportSearchTypeAction.java:205)
at org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction.performFirstPhase(TransportSearchTypeAction.java:192)
at org.elasticsearch.action.search.type.TransportSearchTypeAction$BaseAsyncAction$2.run(TransportSearchTypeAction.java:178)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
at java.lang.Thread.run(Thread.java:779)
Caused by: java.lang.NumberFormatException: For input string: "NaN"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:76)
at java.lang.Long.parseLong(Long.java:452)
at java.lang.Long.parseLong(Long.java:494)
at org.elasticsearch.index.mapper.core.LongFieldMapper.rangeQuery(LongFieldMapper.java:176)
at org.apache.lucene.queryParser.MapperQueryParser.getRangeQuerySingle(MapperQueryParser.java:342)
at org.apache.lucene.queryParser.MapperQueryParser.getRangeQuery(MapperQueryParser.java:331)
at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1496)
at org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1319)
at org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1275)
at org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234)
at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206)
at org.elasticsearch.index.query.QueryStringQueryParser.parse(QueryStringQueryParser.java:212)
at org.elasticsearch.index.query.QueryParseContext.parseInnerQuery(QueryParseContext.java:188)
Please check that the following:
1 - Are you using the developer edition? In Worklight v6, the Analytics console will not function in the developer edition. This may be changed in future releases. I have never seen that exception before, but I wonder if it occurs as a result of trying to run with the developer edition.
2 - In your initOptions.js, analytics has been set to true:
analytics : { enabled: true }
3 - In worklight.properties, you should set the queue size to 1 so that analytics are immediately seen on the console
wl.analytics.queue.size=1
Important Note The queue size should only be set to 1 in testing mode, as using 1 will not scale in production mode.
If you continue to have issues, please post more information such as the calls you are making to WL.Analytics.log and your worklight.properties for the analytics.
EDIT
If you are running Worklight 6.0 in development mode, you will need the following flag in worklight.properties:
wl.analytics.debug=true