---
schema_version: "1"
id: 3cde57f9d92898676a2e8412eed13bdfded1760cfc502573a5b4e54141d25661
title: ส่วนที่ 7 - การตรวจสอบความถูกต้อง เครื่องมือ และการแก้ปัญหา
collection: tableau
version: next
locale: th-th
portal_url: https://docs.salesforce.com/tableau/next/th-th/guides/enterprise-deployment/edg_part7.md
canonical_url: https://help.tableau.com/v0.0/guides/enterprise-deployment/th-th/edg_part7.htm
source_site: help.tableau.com
content_type: documentation
content_hash: 5754822dee14c160d87a544c66bdb5bc622c155d54a4e1335171f14062777ffe
description: "Part 7: validate, troubleshoot, and recover the enterprise deployment, including failover."
---
[ข้ามไปยังเนื้อหาหลัก](#main-content)

# ส่วนที่ 7 - การตรวจสอบความถูกต้อง เครื่องมือ และการแก้ปัญหา

**หมายเหตุ**: Tableau จะไม่อัปเดตคู่มือการปรับใช้ในองค์กรอีกต่อไป แม้ว่าเรายังคงแนะนําสถาปัตยกรรมอ้างอิงที่อธิบายไว้ในที่นี้ว่าเป็นโมเดลการปรับใช้ที่ถูกต้องสําหรับ Tableau Server ใน AWS แต่ขั้นตอนการกําหนดค่าเฉพาะอาจมีการเปลี่ยนแปลงตั้งแต่การอัปเดตครั้งล่าสุด ควรตรวจสอบขั้นตอนเหล่านี้กับเอกสาร[ความช่วยเหลือล่าสุดของ Tableau Server](https://help.tableau.com/current/server/th-th/get_started_server.htm) เสมอ เพื่อให้มั่นใจในความถูกต้อง

หัวข้อนี้ประกอบด้วยขั้นตอนการตรวจสอบหลังการติดตั้งและคำแนะนำในการแก้ปัญหา

## การตรวจสอบการเปลี่ยนระบบเมื่อผิดพลาด

เมื่อกำหนดค่าการปรับใช้แล้ว เราขอแนะนำให้เรียกใช้การทดสอบการเปลี่ยนระบบเมื่อผิดพลาดอย่างง่ายเพื่อตรวจสอบความซ้ำซ้อนของระบบ

เราขอแนะนำให้ทำตามขั้นตอนต่อไปนี้เพื่อตรวจสอบการทำงานเมื่อเกิดข้อผิดพลาด

1. ปิดอินสแตนซ์แรกของเกตเวย์อิสระ (TSIG1) การรับส่งข้อมูลขาเข้าทั้งหมดควรกำหนดเส้นทางผ่านอินสแตนซ์ที่สองของเกตเวย์อิสระ (TSIG2)
2. รีสตาร์ท TSIG1 แล้วปิด TSIG2 การรับส่งข้อมูลขาเข้าทั้งหมดควรกำหนดเส้นทางผ่าน TSIG1
3. รีสตาร์ท TSIG2
4. ปิดโหนด 1 ของ Tableau Server การรับส่งข้อมูลบริการ Vizportal/แอปพลิเคชันทั้งหมดจะล้มเหลวบนโหนด 2
    
    **หมายเหตุ** ตั้งแต่เดือนกันยายน 2022 ความพร้อมใช้งานสูงของโหนด 1 ลดลงสำหรับบางเวอร์ชันของ Tableau Server 2021.4 ขึ้นไป การเชื่อมต่อไคลเอ็นต์จะล้มเหลวหากโหนด 1 ไม่ทำงาน ปัญหานี้ได้รับการแก้ไขแล้วในการเผยแพร่การบำรุงรักษาต่อไปนี้  
      
    \- 2021.4.15 ขึ้นไป  
    \- 2022.1.11 ขึ้นไป  
    \- 2023.1.3 ขึ้นไป  
      
    เพื่อให้แน่ใจว่าการติดตั้ง Tableau Server ของคุณโดยใช้การเปิดใช้งาน ATR จะมีระยะเวลาผ่อนผัน 72 ชั่วโมงหลังจากโหนดเริ่มต้นล้มเหลว ให้ติดตั้งหรืออัปเกรดเป็นเวอร์ชันใดเวอร์ชันหนึ่งเหล่านี้ หากต้องการรายละเอียดเพิ่มเติม โปรดดู [Tableau Server HA ที่ใช้ ATR ไม่มีระยะเวลาผ่อนผันหลังจากความล้มเหลวของโหนดเริ่มต้น](https://kb.tableau.com/articles/issue/tableau-server-ha-using-atr-does-not-have-a-grace-period-after-the-initial-node-failure?lang=th-th "บทความ Tableau KB เกี่ยวกับความล้มเหลวของความพร้อมใช้งานสูง")ในฐานความรู้ Tableau
5. รีสตาร์ทโหนด 1 และปิดโหนด 2 การรับส่งข้อมูลบริการ Vizportal/แอปพลิเคชันทั้งหมดจะล้มเหลวบนโหนด 1
6. รีสตาร์ทโหนด 2

ในบริบทนี้ "การปิดระบบ" หรือ "การรีสตาร์ท" ทำได้โดยการปิดระบบปฏิบัติการหรือเครื่องเสมือนโดยไม่ต้องพยายามปิดแอปพลิเคชันล่วงหน้า เป้าหมายคือการจำลองความล้มเหลวของฮาร์ดแวร์หรือเครื่องเสมือน

ขั้นตอนการตรวจสอบขั้นต่ำสำหรับการทดสอบการเปลี่ยนระบบเมื่อผิดพลาดแต่ละครั้งคือการตรวจสอบสิทธิกับผู้ใช้และดำเนินการดูพื้นฐาน

คุณอาจได้รับข้อผิดพลาดของเบราว์เซอร์ "คำขอไม่ถูกต้อง" เมื่อพยายามเข้าสู่ระบบหลังจากการจำลองความล้มเหลว คุณอาจพบข้อผิดพลาดนี้แม้ว่าคุณจะล้างแคชในเบราว์เซอร์แล้วก็ตาม ปัญหานี้มักจะเกิดขึ้นเมื่อเบราว์เซอร์แคชข้อมูลจากเซสชัน IdP ก่อนหน้า หากข้อผิดพลาดนี้ยังคงอยู่แม้ภายหลังจากที่ล้างแคชของเบราว์เซอร์ในเครื่องไปแล้ว ลองตรวจสอบสถานการณ์ของ Tableau โดยการเชื่อมต่อกับเบราว์เซอร์อื่น

## การกู้คืนโหนดเริ่มต้นอัตโนมัติ

Tableau Server เวอร์ชัน 2021.2.4 และใหม่กว่ามีสคริปต์การกู้คืนโหนดเริ่มต้นอัตโนมัติ `auto-node-recovery` ในไดเรกทอรีสคริปต์ (`/app/tableau_server/packages/scripts.<version>`)

หากโหนดเริ่มต้นมีปัญหาและคุณมีกระบวนการที่ซ้ำกันบนโหนด 2 ไม่มีอะไรรับประกันว่า Tableau Server จะทำงานต่อไปได้ Tableau Server อาจทำงานต่อไปได้ถึง 72 ชั่วโมงหลังจากโหนดเริ่มต้นล้มเหลว ก่อนที่ความผิดพลาดของบริการให้สิทธิ์อนุญาตจะส่งผลต่อกระบวนการอื่นๆ หากเป็นเช่นนั้น ผู้ใช้อาจดำเนินการเข้าสู่ระบบ ดู และใช้เนื้อหาต่อได้หลังจากที่โหนดเริ่มต้นล้มเหลว แต่คุณจะไม่สามารถกำหนดค่า Tableau Server อีกครั้งได้เนื่องจากคุณจะไม่มีสิทธิ์เข้าถึง "ตัวควบคุมการดูแลระบบ"

ถึงแม้จะกำหนดค่าด้วยกระบวนการที่ซ้ำกันแล้ว แต่ก็เป็นไปได้ที่ Tableau Server อาจไม่ทำงานต่อไปหลังจากโหนดเริ่มต้นล้มเหลว

หากต้องการกู้คืนโหนดเริ่มต้น (โหนด 1) ที่ล้มเหลวให้ดำเนินการดังนี้:

1. เข้าสู่ระบบโหนด 2 Tableau Server
2. เปลี่ยนเป็นไดเรกทอรีสคริปต์ดังนี้:
    
    cd /app/tableau\_server/packages/scripts.<version>
3. เรียกใช้คำสั่งต่อไปนี้เพื่อเปิดใช้สคริปต์:
    
    sudo ./auto-node-recovery -p node1 -n node2 -k <license keys>
    
    โดยที่ `<license keys>` เป็นรายการที่คั่นด้วยจุลภาค (ไม่มีช่องว่าง) ของคีย์ให้สิทธิ์อนุญาตสำหรับการปรับใช้ของคุณ หากคุณไม่มีสิทธิ์เข้าถึงคีย์ให้สิทธิ์อนุญาต โปรดไปที่[พอร์ทัลลูกค้า Tableau](http://customer.tableausoftware.com/?_fsi=v45oWMAM) เพื่อกู้คืนข้อมูลเหล่านั้น ตัวอย่าง:
    
    sudo ./auto-node-recovery -p node1 -n node2 -k TSB4-8675-309F-TW50-9RUS,TSNM-559N-ULL6-22VE-SIEN

สคริปต์การกู้คืนโหนดอัตโนมัติจะดำเนินการประมาณ 20 ขั้นตอนเพื่อกู้คืนบริการไปยังโหนด 2 แต่ละขั้นตอนจะแสดงในเทอร์มินัลตามความก้าวหน้าของสคริปต์ สถานะรายละเอียดเพิ่มเติมจะถูกบันทึกลงใน `/data/tableau_data/logs/app-controller-move.log`. ในสภาพแวดล้อมส่วนใหญ่ สคริปต์จะใช้เวลาประมาณ 35 ถึง 45 นาทีจึงเสร็จสมบูรณ์

### การแก้ปัญหาการกู้คืนโหนดเริ่มต้น

หากการกู้คืนโหนดล้มเหลว คุณอาจพบว่าการเรียกใช้สคริปต์แบบโต้ตอบเพื่ออนุญาตหรือไม่อนุญาตขั้นตอนแบบแยกกันในกระบวนการนี้มีประโยชน์ ตัวอย่างเช่น หากสคริปต์ล้มเหลวในระหว่างกระบวนการ คุณสามารถตรวจสอบไฟล์บันทึก เปลี่ยนการกำหนดค่า จากนั้นเรียกใช้สคริปต์อีกครั้ง เมื่อทำงานในโหมดโต้ตอบ คุณสามารถข้ามขั้นตอนทั้งหมดจนกว่าจะถึงขั้นตอนที่ล้มเหลว

หากต้องการทำงานในโหมดโต้ตอบ ให้เพิ่มสวิตช์ `-i` ไปยังอาร์กิวเมนต์สคริปต์

### การสร้างโหนดที่ล้มเหลวขึ้นใหม่

หลังจากที่คุณเรียกใช้สคริปต์แล้ว โหนด 2 จะเรียกใช้บริการทั้งหมดที่เคยอยู่บนโฮสต์โหนด 1 ที่ล้มเหลว หากต้องการเพิ่มลงในโหนด 4 คุณต้องปรับใช้โฮสต์ Tableau Server ล่าสุดด้วยไฟล์ Bootstrap และกำหนดค่าเช่นเดียวกับโหนด 2 ดั้งเดิมตามที่ระบุไว้ในส่วนที่ 4 โปรดดู[กำหนดค่าโหนด 2](https://help.tableau.com/v0.0/guides/enterprise-deployment/th-th/edg_part4.htm#Configur2)

## switchto

switchto เป็นสคริปต์จาก Tim ที่ช่วยให้การสลับระหว่างหน้าต่างทำได้ง่าย

1. คัดลอกโค้ดต่อไปนี้ลงในไฟล์ชื่อ `switchto` ในโฮมไดเรกทอรีบนโฮสต์ Bastion ของคุณ

#!/bin/bash
#-------------------------------------------------------------------
# switchto
#
# Helper function to simplify SSH into the various AWS hosts when
# following the Tableau Server Enterprise Deployment Guide (EDG).
#
# Place this file on your bastion host and provide your AWS hosts' 
# internal ip addresses or machine names here.
# Example: readonly NODE1="10.0.3.187"
#
readonly NODE1=""
readonly NODE2=""
readonly NODE3=""
readonly NODE4=""
readonly PGSQL=""
readonly PROXY1=""
readonly PROXY2=""
				
usage() {
echo "Usage: switchto.sh \[ node1 | node2 | node3 | node4 | pgsql | proxy1 | proxy2 \]"
}


ip=""

case $1 in
	node1)
		ip="$NODE1"
		;;
	node2)
		ip="$NODE2"
		;;
	node3)
		ip="$NODE3"
		;;
	node4)
		ip="$NODE4"
		;;
	pgsql)
		ip="$PGSQL"
		;;
	proxy1)
		ip="$PROXY1"
		;;
	proxy2)
		ip="$PROXY2"
		;;
	?)
		usage
		exit 0
		;;
	\*)
		echo "Unkown option $1."
		usage
		exit 1
		;;
esac

if \[\[ -z $ip \]\]; then
echo "You must first edit this file to provide the ip addresses of your AWS hosts."
exit 1
fi

ssh -A ec2-user@$ip

3. อัปเดตที่อยู่ IP ในสคริปต์เพื่อจับคู่กับอินสแตนซ์ EC2 จากนั้นบันทึกไฟล์
4. ใช้สิทธิ์กับไฟล์สคริปต์:

sudo chmod +x switchto

การใช้งาน:

หากต้องการสลับไปยังโฮสต์ ให้เรียกใช้คำสั่งต่อไปนี้:

`./switchto <target>`

ตัวอย่างเช่น สลับไปยังโหนด 1 ให้เรียกใช้คำสั่งต่อไปนี้:

`./switchto node1`

## การแก้ปัญหาเกตเวย์อิสระของ Tableau Server

การกำหนดค่าเกตเวย์อิสระ Okta, Mellon และ SAML บน Tableau Server เป็นกระบวนการที่อาจเกิดข้อผิดพลาดได้ สาเหตุทั่วไปของความผิดพลาดคือข้อผิดพลาดจากสตริง ตัวอย่างเช่น เครื่องหมายทับปิดท้าย (`/`) บน URL ของ Okta ที่กำหนดระหว่างการกำหนดค่าอาจทำให้เกิดข้อผิดพลาดที่ไม่ตรงกัน ซึ่งเกี่ยวข้องกับการยืนยัน SAML นี่เป็นเพียงตัวอย่างหนึ่ง มีโอกาสสูงที่จะป้อนสตริงไม่ถูกต้องในแอปพลิเคชันใดๆ ในระหว่างการกำหนดค่ามีสูง

### รีสตาร์ทบริการ tableau-tsig

ต้องเริ่ม (และดำเนินการให้เสร็จ) การแก้ปัญหาโดยการรีสตาร์ทบริการ tableau-tsig บนคอมพิวเตอร์เกตเวย์อิสระ การรีสตาร์ทบริการจะเป็นการทริกเกอร์การกำหนดค่าที่อัปเดตเพื่อให้โหลดจากTableau Server อย่างรวดเร็วและบ่อยครั้ง

เรียกใช้คำสั่งต่อไปนี้บนคอมพิวเตอร์เกตเวย์อิสระ:

sudo su - tableau-tsig

systemctl --user restart tsig-httpd

exit

### ค้นหาสตริงที่ไม่ถูกต้อง

หากคุณพบข้อผิดพลาดจากสตริง (คัดลอก/วางโดยไม่ตั้งใจ สตริงถูกตัดทอน ฯลฯ) ให้ใช้เวลาสำรวจการตั้งค่าแต่ละข้อที่คุณกำหนดค่าไปแล้ว:

- การกำหนดค่าการตรวจสอบสิทธิ์ล่วงหน้าของ Okta ตรวจสอบ URL ที่คุณตั้งอย่างละเอียด ตรวจดูเครื่องหมายทับปิดท้าย ตรวจสอบ HTTP และ HTTPS
- ประวัติเชลล์สำหรับการกำหนดค่า SAML บนโหนด 1 ตรวจทานคำสั่ง `tsm authentication saml configure` ที่คุณเรียกใช้ ตรวจสอบว่า URL ทั้งหมดตรงกับ URL ที่คุณกำหนดค่าใน Okta ขณะที่คุณกำลังตรวจสอบประวัติเชลล์จากโหนด 1 ให้ตรวจสอบว่าคำสั่ง `tsm configuration set` ที่ระบุเส้นทางของไฟล์การกำหนดค่า Mellon ตรงกับเส้นทางของไฟล์ที่คุณคัดลอกไฟล์บนเกตเวย์อิสระ
- การกำหนดค่า Mellon บนเกตเวย์อิสระ ตรวจทานประวัติเชลล์เพื่อตรวจสอบว่าคุณสร้างเมตาดาต้าโดยใช้สตริง URL เดียวกันกับที่คุณกำหนดค่าใน Okta และ Tableau SAML ตรวจสอบว่าเส้นทางทั้งหมดที่ระบุใน `/etc/mellon/conf.d/global.conf` ถูกต้องและตั้ง `MellonCookieDomain` เป็นโดเมนรูท ไม่ใช่โดเมนย่อยของ Tableau

### ค้นหาบันทึกที่เกี่ยวข้อง

หากสตริงทั้งหมดตั้งค่าอย่างถูกต้องแล้ว คุณควรตรวจดูบันทึกเพื่อหาข้อผิดพลาด

Tableau Server จะบันทึกข้อผิดพลาดและเหตุการณ์ต่างๆ เป็นไฟล์บันทึกต่างๆ หลายสิบไฟล์ บันทึกของเกตเวย์อิสระก็เป็นหนึ่งในไฟล์ที่อยู่ในเครื่องเช่นกัน เราขอแนะนำให้ตรวจสอบไฟล์บันทึกตามลำดับต่อไปนี้

#### ไฟล์บันทึกเกตเวย์อิสระ

ตำแหน่งตามค่าเริ่มต้นของไฟล์บันทึกของเกตเวย์อิสระจะอยู่ที่ `/var/opt/tableau/tableau_tsig/logs`

- `access.log`: บันทึกนี้จะมีประโยชน์เมื่อมีรายการที่แสดงการเชื่อมต่อจากโหนดต่างๆ ของ Tableau Server หากคุณได้รับข้อผิดพลาดของเกตเวย์ (ไม่เริ่มทำงาน) เมื่อคุณพยายามเริ่ม TSM และไม่มีรายการบันทึกในไฟล์ `access.log` แสดงว่าการเชื่อมต่อหลักมีปัญหา ต้องตรวจสอบการกำหนดค่ากลุ่มการรักษาความปลอดภัย AWS เป็นขั้นตอนแรกเสมอ ปัญหาทั่วไปอื่นๆ คือการพิมพ์ผิดใน `tsig.json` หากคุณทำการอัปเดต tsig.json ให้เรียกใช้คำสั่ง `tsm stop` ก่อนเรียกใช้ `tsm topology external-services gateway update -c tsig.json` หลังจากที่อัปเดต tsig.json แล้วให้เรียกใช้คำสั่ง `tsm start`
- `error.log`: เมื่อเทียบกับรายการอื่นๆ บันทึกนี้จะรวมข้อผิดพลาดของ SAML และ Mellon

#### ไฟล์บันทึก tabadminagent ของ Tableau Server

ชุดของไฟล์ `tabadminagent` (not `tabadmincontroller`) คือไฟล์บันทึกที่เกี่ยวข้องเพียงชุดเดียวสำหรับการแก้ปัญหาข้อผิดพลาดที่เกี่ยวข้องกับเกตเวย์อิสระ

คุณต้องค้นหาว่ามีการบันทึกข้อผิดพลาดของเกตเวย์อิสระไว้ที่ใดใน `tabdminagent` ข้อผิดพลาดเหล่านี้อาจเป็นโหนดใดๆ ก็ได้ แต่จะมีเพียงโหนดเดียว ทำตามขั้นตอนต่อไปนี้กับแต่ละโหนดในคลัสเตอร์ของ Tableau Server จนว่าคุณจะพบสตริงที่พิมพ์เป็น “independent”:

1. ระบุตำแหน่งของไฟล์บันทึก tabadminagent บนโหนด 1-4 ของ Tableau Server ในการตั้งค่า EDG setup:
    
    cd /data/tableau\_data/data/tabsvc/logs/tabadminagent
2. เปิดบันทึกล่าสุดเพื่ออ่าน:
    
    less tabadminagent\_nodeN.log
    
    (แทนที่ N ด้วยหมายเลขของโหนด)
3. ค้นหาอินสแตนซ์ทั้งหมดที่พิมพ์ “Independent” และ “independent” โดยใช้สตริงการค้นหาต่อไปนี้
    
    /ndependent
    
    หากไม่มีผลการค้นหาที่ตรงกัน ให้ข้ามไปที่โหนดถัดไป และทำซ้ำขั้นตอนที่ 1-3
4. เมื่อค้นหาพบแล้ว ให้กด `Shift + G` เพื่อไปยังด้านล่าง และดูข้อความข้อผิดพลาดล่าสุด

### โหลดไฟล์ httpd stub ซ้ำ

เกตเวย์อิสระจะจัดการการกำหนดค่าของ httpd สำหรับ Apache การดำเนินการทั่วไปที่มักจะแก้ไขปัญหาได้แบบชั่วคราวคือ การโหลดไฟล์ httpd stub ซ้ำซึ่งสร้างการกำหนดค่า Apache เบื้องหลัง เรียกใช้คำสั่งต่อไปนี้บนทั้งสองอินสแตนซ์ของเกตเวย์อิสระ

1. คัดลอกไฟล์ stub ไปที่ httpd.conf:
    
    cp /var/opt/tableau/tableau\_tsig/config/httpd.conf.stub /var/opt/tableau/tableau\_tsig/config/httpd.conf
2. รีสตาร์ทบริการเกตเวย์อิสระ:
    
    sudo su - tableau-tsig
    systemctl --user restart tsig-httpd
    exit

### ลบหรือย้ายไฟล์บันทึกเก่า

เกตเวย์อิสระจะบันทึกเหตุการณ์การเข้าถึงทั้งหมด คุณจะต้องจัดการพื้นที่จัดเก็บไฟล์บันทึกเพื่อหลีกเลี่ยงการใช้พื้นที่ว่างในดิสก์ หากดิสก์ของคุณเต็ม เกตเวย์อิสระจะไม่สามารถเขียนเหตุการณ์การเข้าถึงได้และบริการก็จะล้มเหลว ข้อความต่อไปนี้จะบันทึกลงใน error.log บนเกตเวย์อิสระ:

(28)No space left on device: \[client 10.0.2.209:54332\] AH00646: Error writing to /var/opt/tableau/tableau\_tsig/logs/access.%Y\_%m\_%d\_%H\_%M\_%S.log

ความล้มเหลวนี้จะส่งผลให้เกิดสถานะ `DEGRADED` สำหรับโหนด `external` เมื่อคุณเรียกใช้ `tsm status -v` บน โหนด 1 ของ Tableau โหนด `external` ในเอาต์พุตสถานะจะอ้างอิงเกตเวย์อิสระ

หากต้ิงการแก้ปัญหานี้ ให้ลบหรือย้ายไฟล์ access.log ออกจากดิสก์ ไฟล์ Access.log จะจัดเก็บไว้ใน `/var/opt/tableau/tableau_tsig/logs` เมื่อล้างดิสก์แล้ว รีสตาร์ทบริการ tableau-tsig

### ข้อผิดพลาดของเบราว์เซอร์

**คำขอไม่ถูกต้อง**: ข้อผิดพลาดทั่วไปสำหรับสถานการณ์นี้คือข้อผิดพลาด “คำขอไม่ถูกต้อง” จาก Okta ปัญหานี้มักจะเกิดขึ้นเมื่อเบราว์เซอร์แคชข้อมูลจากเซสชัน Okta ก่อนหน้า ตัวอย่างเช่น หากคุณจัดการแอปพลิเคชัน Okta ในฐานะผู้ดูแลระบบ Okta และพยายามเข้าถึง Tableau โดยใช้บัญชีอื่นที่เปิดใช้งาน Okta ข้อมูลเซสชันจากข้อมูลผู้ดูแลระบบอาจทำให้เกิดข้อผิดพลาด “คำขอไม่ถูกต้อง” หากข้อผิดพลาดนี้ยังคงอยู่แม้ภายหลังจากที่ล้างแคชของเบราว์เซอร์ในเครื่องไปแล้ว ลองตรวจสอบสถานการณ์ของ Tableau โดยการเชื่อมต่อกับเบราว์เซอร์อื่น

สาเหตุอื่นของข้อผิดพลาด “คำขอไม่ถูกต้อง” คือการพิมพ์ผิดใน URL รายการใดรายการหนึ่งที่ป้อนระหว่างกระบวนการกำหนดค่า Okta, Mellon และ SAML ตรวจดูว่าคุณป้อนค่าต่อไปนี้โดยไม่ผิดพลาด

โดยทั่วไปแล้ว ไฟล์ `error.log` บนเซิร์ฟเวอร์ของเกตเวย์อิสระจะระบุ URL ที่ทำให้เกิดข้อผิดพลาด

**ไม่พบ - ไม่พบ URL ที่ขอในเซิร์ฟเวอร์นี้**: ข้อผิดพลาดนี้แสดงถึงหนึ่งในข้อผิดพลาดในการกำหนดค่า

หากผู้ใช้ได้รับการตรวจสอบสิทธิ์กับ Okta แล้วได้รับข้อผิดพลาดนี้ เป็นไปได้ว่าคุณได้อัปโหลดแอปพลิเคชันการตรวจสอบสิทธิ์ล่วงหน้าของ Okta ไปยัง Tableau Server เมื่อกำหนดค่า SAML ตรวจสอบว่าคุณมีเมตาดาต้าของแอปพลิเคชัน Tableau Server ใน Okta ที่กำหนดค่าบน Tableau Server ไม่ใช่เมตาดาต้าของแอปพลิเคชันการตรวจสอบสิทธิ์ล่วงหน้าของ Okta

ขั้นตอนการแก้ปัญหาอื่นๆ มีดังนี้

- ตรวจสอบการตั้งค่าแอปพลิเคชันการตรวจสอบสิทธิ์ล่วงหน้าของ Okta ตรวจสอบว่าได้ตั้งค่าโปรโตคอล HTTP กับ HTTPS ตามที่ระบุไว้ในหัวข้อนี้
- รีสตาร์ท tsig-httpd บนเซิร์ฟเวอร์เกตเวย์อิสระทั้ง
- ตรวจสอบว่า `sudo apachectl configtest` แสดงค่า “Syntax OK” บนเกตเวย์อิสระทั้งสองเซิร์ฟเวอร์
- ตรวจสอบว่าได้กำหนดผู้ใช้ทดสอบให้กับทั้งสองแอปพลิเคชันใน Okta
- ตรวจสอบว่าได้ตั้งค่าความสามารถในการดึงดูดบนตัวจัดสรรภาระงานและกลุ่มเป้าหมายที่เกี่ยวข้อง

### ตรวจสอบยืนยันการเชื่อมต่อ TLS จาก Tableau Server ไปยังเกตเวย์อิสระ

ใช้คำสั่ง `wget` เพื่อยืนยันความสามารถในการเชื่อมต่อและการเข้าถึงจาก Tableau Server ไปยังเกตเวย์อิสระ ลักษณะต่างๆ ของคำสั่งนี้สามารถช่วยให้คุณเข้าใจว่าปัญหาเกี่ยวกับใบรับรองก่อให้เกิดปัญหาการเชื่อมต่อหรือไม่

ตัวอย่างเช่น เรียกใช้คำสั่ง `wget` นี้เพื่อตรวจสอบยืนยันโปรโตคอล (HK) จาก Tableau Server:

`wget https://ip-10-0-1-38.us-west-1.compute.internal:21319`

สร้าง URL ด้วยที่อยู่โฮสต์เดียวกันที่คุณรวมอยู่ในตัวเลือกโฮสต์ของไฟล์ tsig.json ระบุโปรโตคอล `https` และผนวก URL กับพอร์ต HK `21319`

วิธีการตรวจสอบการเชื่อมต่อและเพิกเฉยต่อการตรวจสอบยืนยันใบรับรอง:

`wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate`

วิธีการตรวจสอบว่าใบรับรอง CA สำหรับ TSIG มีความถูกต้อง:

`wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem`

หาก Tableau สามารถสื่อสารได้ คุณอาจยังได้รับข้อผิดพลาดที่เกี่ยวข้องกับเนื้อหา แต่คุณจะไม่ได้รับข้อผิดพลาดที่เกี่ยวข้องกับการเชื่อมต่อ หาก Tableau ไม่สามารถทำการเชื่อมต่อใดๆ ได้เลย ก็ให้เริ่มต้นจากการตรวจสอบยืนยันการกำหนดค่าโปรโตคอลในกลุ่มไฟร์วอลล์/ความปลอดภัย ตัวอย่างเช่น กฎขาเข้าของกลุ่มความปลอดภัยที่มีเกตเวย์อิสระอยู่ในนั้นจะต้องอนุญาต TCP 21319