I finid that at {wso2am_home}repository/logs/ have logs:
http_access_2013-10-28.log
tm.out wso2-apigw-errors.log
wso2-apigw-service.log
wso2-apigw-trace.log
wso2carbon-trace-messages.log
wso2carbon.log
and I configure all the log4j.properties INFO to OFF. I don't know where to close the http_access.log.
I find when I call 1 time api,it write the http_access.log: gwmanager.apim-wso2.com:8280 - - - "GET /direct/1.0.5 HTTP/1.1" - - "-" "Jakarta Commons-HttpClient/3.1" 128.6.X.X:80 - - - "GET http://128.6.X.X:80 HTTP/1.1" - - "-" "Synapse-HttpComponents-NIO so,as I call api time more and more ,the file is more and ---------- more big.
Do you know how to close the http_access.log?
If you want to disable http access logs in WSO2 products then go to catalina-server.xml which is located {CARBON_HOME}/repository/conf/tomcat directory, and remove the following property
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="${carbon.home}/repository/logs"
prefix="http_access_" suffix=".log"
pattern="combined" />
Please refer this for more details
Related
I am using gcloud CLI to configure my region and zone:
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-c
But each command lasts for about 15 seconds, and I get a warning:
WARNING: Property validation for compute/region was skipped
Everything works fine, but why do I have 15 seconds delay, and a warning?
With verbose argument, the output is:
DEBUG: Running [gcloud.config.set] with arguments: [--verbosity: "debug", SECTION/PROPERTY: "compute/region", VALUE: "us-central1"]
Updated property [compute/region].
DEBUG: Making request: GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/?recursive=true
DEBUG: Starting new HTTP connection (1): metadata.google.internal:80
DEBUG: http://metadata.google.internal:80 "GET /computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/?recursive=true HTTP/1.1" 200 185
DEBUG: Making request: GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/token
DEBUG: http://metadata.google.internal:80 "GET /computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/token HTTP/1.1" 200 1050
DEBUG: Making request: GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/?recursive=true
DEBUG: Starting new HTTP connection (1): metadata.google.internal:80
DEBUG: http://metadata.google.internal:80 "GET /computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/?recursive=true HTTP/1.1" 200 185
DEBUG: Making request: GET http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/token
DEBUG: http://metadata.google.internal:80 "GET /computeMetadata/v1/instance/service-accounts/GOOGLE_AACOUNT_REPLACED#cloudbuild.gserviceaccount.com/token HTTP/1.1" 200 1050
DEBUG: Starting new HTTPS connection (1): compute.googleapis.com:443
DEBUG: https://compute.googleapis.com:443 "POST /batch/compute/v1 HTTP/1.1" 200 None
DEBUG: https://compute.googleapis.com:443 "POST /batch/compute/v1 HTTP/1.1" 200 None
DEBUG: https://compute.googleapis.com:443 "POST /batch/compute/v1 HTTP/1.1" 200 None
DEBUG: https://compute.googleapis.com:443 "POST /batch/compute/v1 HTTP/1.1" 200 None
DEBUG: https://compute.googleapis.com:443 "POST /batch/compute/v1 HTTP/1.1" 200 None
WARNING: Property validation for compute/region was skipped.
To make the gcloud tool easier to use, the Google Cloud will try and validate the values provided, including “compute/region”. In this case, it has to fetch a full list of available regions from the API. If this fails, for whatever reason, then it will show this warning message.
One of the many reasons may be that the Compute Engine API is not enabled. It could also be a lack of authentication, although Cloud Build will have authentication enabled by default and you don't need any special permissions to run this command.
To find out what exactly is going wrong, you can try adding the --log-http parameter to your gcloud command line. This will display the full details of any interactions with the API, including any error message in the response.
In any case, this is simply a warning, and the config entry is still being updated. This happens even if the validation fails, e.g. the region does not exist. As I mentioned above, this is just a feature to help letting the user know if they make certain types of simple mistakes.
Setup: Two WSO2 APIM pointing to same MYSQL. These two WSO2 instances are behind a LB and publisher session is sticky. The API session is not sticky. I have published API "/public/1.0.0/abc" which previously pointed to "/api/app/v1/xyz". I updated the published API to now point to "/api/app/v1/abc".
Issue: Now after the update when the published API is accessed through curl, at times returns back expected result but other times it throws 403 error. It seems update in one instance did not propagate to another? Below steps to make it work means downtime and we are trying to avoid the downtime.
The only way to make this work is by doing the following:
1. Shutdown the wso2am app on the working instance (Instance1)
2. Update the API again on WSO2 publisher so Instance2 picks up the change
3. Start back the Instance1 wso2am app
WSO2 Instance1 logs where the call works:
==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/http_access_.log <==
- <private-subnet-ip> - - [04/Jun/2019:20:02:00 +0000] "GET /services/Version HTTP/1.1" - - "-" "ELB-HealthChecker/2.0"
<my-ip> <private-subnet-ip> - - [04/Jun/2019:20:02:22 +0000] "GET /public/1.0.0/abc HTTP/1.1" - - "-" "curl/7.54.0"
<my-ip> <private-subnet-ip> - - [04/Jun/2019:20:02:22 +0000] "GET /api/app/v1/abc HTTP/1.1" - - "-" "Synapse-PT-HttpComponents-NIO"
- <private-subnet-ip> - [04/Jun/2019:20:02:00 +0000] "- - " 200 - "-" "-"
- <private-subnet-ip> - [04/Jun/2019:20:02:22 +0000] "- - " 200 - "-" "-"
- <private-subnet-ip> - [04/Jun/2019:20:02:22 +0000] "- - " 200 - "-" "-"
WSO2 Instance2 logs where the call doesnt works:
==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2carbon.log <==
TID: [-1234] [] [2019-06-04 20:01:24,511] WARN {org.apache.synapse.rest.API} - Trying to access API : admin--PublicAPI on restricted transport chanel [https] {org.apache.synapse.rest.API}
==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2-apigw-errors.log <==
2019-06-04 20:01:24,511 [-] [PassThroughMessageProcessor-123] WARN API Trying to access API : admin--PublicAPI on restricted transport chanel [https]
==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2carbon.log <==
TID: [-1234] [] [2019-06-04 20:01:24,511] INFO {org.apache.synapse.mediators.builtin.LogMediator} - STATUS = Message dispatched to the main sequence. Invalid URL., RESOURCE = /public/1.0.0/abc {org.apache.synapse.mediators.builtin.LogMediator}
==> /usr/lib64/wso2/wso2am/2.6.0/repository/logs/wso2-apigw-service.log <==
2019-06-04 20:01:24,511 [-] [PassThroughMessageProcessor-123] INFO __SynapseService STATUS = Message dispatched to the main sequence. Invalid URL., RESOURCE = /public/1.0.0/abc
This happens if you haven't shared the API artifacts between the two servers. Only one server has the updated artifact. When you publish an API, it creates a Synapse(API) artifact which stored in the file system of the server. The location is SERVER_HOME/repository/deployment/server/synapse/default/api location. If you are running more than one instance, you should have a mechanism to sync those artifacts between the servers. There are several options.
Use a shared file system for the nodes
Rsync option - you can keep always point to node 1 and publish the API. From node 1 you can rsync data to the node 2. In the api-manager.xml, APIGateway serverURL should be changed to node 1 in both nodes.
After following the documentation in https://www.odoo.com/documentation/9.0/api_integration.html I have encountered a problem with the generated PDF report.
I call the webservice to generate an invoice report and after rendering the pdf report, it returns without its layout ( located: account.report_invoice )
I do the following to render the report:
url = 'http://{0}:{1}/xmlrpc/2/report'.format(self._connect['host'], self._connect['port'])
sock_print = xmlrpclib.ServerProxy(url)
#Here, the 'render_report' function returns the base64 pdf without the specified layout
result = sock_print.render_report(db_name, uid, pwd, report_name, ids, {'model': 'account.invoice', 'report_type': 'qweb-pdf'})
string_pdf = base64.decodestring(report['result'])
return True, string_pdf
After, the function above is done, I save the file in a directory to check if the file was generated with the correct layout.
So far, the pdf was generated but without its layout for account.report_invoice.
Any ideas on what might be happening or what I might be missing?
Thank you for your time.
[EDIT 1]
2018-09-17 14:34:09,599 30522 INFO ? werkzeug: 127.0.0.1 - - [17/Sep/2018 14:34:09] "GET /web/content/323-c1e807b/report.assets_common.0.css HTTP/1.1" 404 -
2018-09-17 14:34:09,617 30522 INFO ? werkzeug: 127.0.0.1 - - [17/Sep/2018 14:34:09] "GET /web/content/328-9a5a204/report.assets_pdf.0.css HTTP/1.1" 404 -
2018-09-17 14:34:09,879 30522 INFO ? werkzeug: 127.0.0.1 - - [17/Sep/2018 14:34:09] "GET /web/content/328-9a5a204/report.assets_pdf.0.css HTTP/1.1" 404 -
2018-09-17 14:34:09,883 30522 INFO ? werkzeug: 127.0.0.1 - - [17/Sep/2018 14:34:09] "GET /web/content/323-c1e807b/report.assets_common.0.css HTTP/1.1" 404 -
Found this when trying to call via webservice.
When I print the reports directly from odoo interface it's O.K, but via webservice it doesn't recognise its own core css.
Hi i'm in need of some serious help,
I have logs that i wish to Parse using GROK but the problem i'm having is that they are not always consistent in content or spacing here are some obfuscated examples.
title_access_log:ipaddress1, ipaddress2, ipaddress3 - - [14/Nov/2017:08:30:00 +0000] "GET /url HTTP/1.1" 200 198454 - 153261 - 0000fD5b5OSuS2C7ZdhgwqYufJk:GH809 url
title_access_log:ipaddress1, ipaddress2 - - [14/Nov/2017:08:30:00 +0000] "GET /url HTTP/1.1" 200 2326 - 20482 V22843489635e0e42e864037eccb8ad4857500ea 0000BDzHfUFhjJmcs9R4-CyglGS:GH806 url
title_access_log:ipaddress1, ipaddress2 - - [14/Nov/2017:08:30:00 +0000] "POST /url HTTP/1.1" 200 30031 - 17942 - 0000PjpQluI9BZ0w4EDB9o2fow-:GH809 url
I have managed to make a GROK patterns that pull out up to time and date for logs that contain 2 IPs but i get suck going further or when trying to do logs with 3 ips.
Has anyone got any advice on how to tackle this.
i'm using Graylog is what i'm using to extract data to so i do have the option of using other formats than GROK.
While using Call mediator and Send Mediator (calling HTTPS endpoint with username token by using policy at the endpoint)
Getting the following error :
[2015-01-03 03:38:23,058] DEBUG - SynapseCallbackReceiver Callback removed for request message id :
urn:uuid:160c12bd-1286-4ef0-873e-93777380a4a2. Pending callbacks count : 1
[2015-01-03 03:38:23,061] DEBUG - TargetHandler http-outgoing-19: Closed
[2015-01-03 03:38:23,065] DEBUG - TargetHandler http-outgoing-19: Keep-Alive Connection closed
[2015-01-03 03:38:23,064] WARN - SynapseCallbackReceiver Synapse received a response for the reques
t with message Id : urn:uuid:160c12bd-1286-4ef0-873e-93777380a4a2 But a callback is not registered (
anymore) to process this response
[2015-01-03 03:38:23,067] DEBUG - LoggingNHttpClientConnection http-outgoing-19: Shutdown connection
[2015-01-03 03:38:51,472] DEBUG - access - 68.232.203.67 - - [03/Jan/2015:03:38:51 +0530] "POST /Ser
vice.asmx HTTP/1.1" - - "-" "Synapse-PT-HttpComponents-NIO"
[2015-01-03 03:38:51,476] DEBUG - access - 68.232.203.67 - [03/Jan/2015:03:38:51 +0530] "- - " 200
I can see the expected response on the console WIRE>>
but getting this error and the response is not being correlated
please let me know if anyone has faced this issue earlier and how to resolve this.
Thanks
Reason might be, your service endpoint takes much time to respond. Increase the endpoint timeout value in the endpoint configuration and synapse.global_timeout_interval value in synapse properties file.